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1 Scope 



The present document specifies the Test Suite Structure and Test Purposes (TSS&TP) for NGN/IMS interconnection 
tests at the Ic Interface to verify the overall compatibility of SIP, ISDN and non-ISDN (PSTN) over the national or 
international NGN networks under consideration of the use of End Devices in the relevant networks (recommended by 
the network operator). The TSS&TP specification covers the procedures described in TS 124 229 [2] and 
TS 129 165 [1] respectively. 

The specified Test Purposes are the basis for bilateral tests between national or international network operators. Even if 
tests between network operators is agreed, exactly the test purposes defined in the current document are be performed. 
Modification of the requirements as described in TS 124 229 [2] and TS 129 165 [1] based on national requirements 
needs additional Test Purposes not described in the present document. This additional test may be defined and agreed 
between the test staff of the network operators. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
reference document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[1] ETSI TS 129 165: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Inter-IMS Network to Network Interface (NNI) 
(3GPP TS 29.165 Release 10)". 

[2] ETSI TS 124 229: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; IP multimedia call control protocol based on Session 
Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 
(3GPP TS 24.229 Release 10)". 

[3] IETF RFC 4566 (2006): "SDP: Session Description Protocol". 

[4] IETF RFC 3261 (2002): "SIP: Session Initiation Protocol". 

[5] IETF RFC 3264 (2002): "An Offer/Answer Model with the Session Description Protocol (SDP)". 

[6] IETF RFC 3312 (2002): "Integration of Resource Management and Session Initiation 

Protocol (SIP)". 

[7] ETSI TS 124 607: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Originating Identification Presentation (OIP) and 
Originating Identification Restriction (OIR) using IP Multimedia (IM) Core Network (CN) 
subsystem; Protocol specification (3GPP TS 24.607 Release 10)". 

[8] ETSI TS 124 608: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Terminating Identification Presentation (TIP) and 
Terminating Identification Restriction (TIR) using IP Multimedia (IM) Core Network (CN) 
subsystem; Protocol specification (3GPP TS 24.608 Release 10)". 
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[9] ETSI TS 124 604: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Communication Diversion (CDIV) using IP 
Multimedia (IM) Core Network (CN) subsystem; Protocol specification 
(3GPP TS 24.604 version 10.3.0 Release 10)". 

[10] ETSI TS 124 605: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Conference (CONE) using IP Multimedia (IM) Core 
Network (CN) subsystem; Protocol specification (3GPP TS 24.605 Release 10)". 

[11] ETSI TS 124 629: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Explicit Communication Transfer (ECT) using IP 
Multimedia (IM) Core Network (CN) subsystem; Protocol specification 
(3GPP TS 24.629 Release 10)". 

[12] ETSI TS 124 611: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Anonymous Communication Rejection (ACR) and 
Communication Barring (CB) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol 
specification (3GPP TS 24.611 Release 10)". 

[13] ETSI TS 124 654: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Closed User Group (CUG) using IP Multimedia (IM) 
Core Network (CN) subsystem, Protocol Specification (3GPP TS 24.654 Release 10)". 

[14] ETSI TS 124 642: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Completion of Communications to Busy Subscriber 
(CCBS) and Completion of Communications by No Reply (CCNR) using IP Multimedia (IM) 
Core Network (CN) subsystem; Protocol Specification (3GPP TS 24.642 Release 10)". 

[15] ETSI TS 124 615: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Communication Waiting (CW) using IP Multimedia 
(IM) Core Network (CN) subsystem; Protocol Specification (3GPP TS 24.615 Release 10)". 

[16] ETSI TS 124 606: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Message Waiting Indication (MWI) using IP 
Multimedia (IM) Core Network (CN) subsystem; Protocol specification 
(3GPP TS 24.606 Release 10)". 

[17] ETSI TS 124 610: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Communication HOLD (HOLD) using IP 
Multimedia (IM) Core Network (CN) subsystem; Protocol specification 
(3GPP TS 24.610 Release 10)". 

[18] ETSI TS 124 616: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Malicious Communication Identification (MCID) 
using IP Multimedia (IM) Core Network (CN) subsystem; Protocol specification 
(3GPP TS 24.616 Release 10)". 

[19] ETSI TS 129 658: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; TISPAN; SIP Transfer of IP Multimedia Service 
Tariff Information; Protocol specification (3GPP TS 29.658 Release 10)". 

[20] ETSI TS 124 628: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Common Basic Communication procedures using IP 
Multimedia (IM) Core Network (CN) subsystem; Protocol specification 
(3GPP TS 24.628 Release 10)". 

[21] IETF RFC 5009 (September 2007): "Private header (P-Header) extension to the Session Initiation 

Protocol (SIP) for authorization of Early Media" . 

[22] ITU-T Recommendation V.152 (November 2004): "Procedures for supporting Voice-Band Data 

over IP Networks". 

[23] ITU-T Recommendation T.38 (September 2010, prepublished): "Procedures for real-time 

Group 3 facsimile communication over IP networks". 
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[24] ITU-T Recommendation Q. 1912.5: "SERIES Q: SWITCHING AND SIGNALLING 

Specifications of signalling related to Bearer Independent Call Control (BICC) Interworking 
between Session Initiation Protocol (SIP) and Bearer Independent Call Control protocol or ISDN 
User Part". 

[25] ETSI TS 183 036: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); ISDN/SIP interworking; Protocol specification". 

2.2 Informative references 

The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

[i. 1] ETSI EN 300 403-1 : "Integrated Services Digital Network (ISDN); Digital Subscriber Signalling 

System No. one (DSSl) protocol; Signalling network layer for circuit-mode basic call control; 
Part 1: Protocol specification [ITU-T Recommendation Q.931 (1993), modified]". 

[i.2] ISO/IEC 9646 (1994): "Information technology ~ Open Systems Interconnection ~ Conformance 

testing methodology and framework" . 

[i.3] ETSI TR 102 775 (Vl.5.1): "Speech and multimedia Transmission Quality (STQ); Guidance on 

objectives for Quality related Parameters at VoIP Segment-Connection Points; A support to NGN 
transmission planners". 

[i.4] ITU-T Recommendation Q. 1902.2 (07/2001): "Bearer Independent Call Control protocol 

(Capability Set 2) and Signalling System No. 7 ISDN User Part: General functions of messages and 
parameters". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

BICC or ISUP specific terminology, references to ITU-T Recommendation Q. 1902.2 [i.4]. For SIP and SDP specific 
terminology, references to RFC 3261 [4] and RFC 4566 [3] respectively. Definitions for additional terminology used in 
this interworking Recommendation are as follows: 

Adjacent SIP Node (ASN): SIP node (e.g. SIP Proxy or Back-to-Back User Agent or the SIP side of an IWU) that has 
established a direct trust relation (association) with Incoming or Outgoing IWU entities 

NOTE: The SIP Proxy and Back-to-Back User Agent are defined in accordance with RFC 3261 [4]. 

Basic Call Control (BCC): signalling protocol associated with the DSSl - ISDN Basic Call control procedures of 
ITU-T recommendation Q.931 [15] (EN 300 403-1 [i.l]) 

Incoming Interworking Unit (I-IWU): physical entity, (which can be combined with a BICC ISN or ISUPexchange) 
that terminates incoming calls using SIP and originates outgoing calls using the BICC or ISUP protocols 

incoming or outgoing: direction of a call (not signalling information) with respect to a reference point 

incoming SIP or BICC/ISUP (network): network, from which the incoming calls are received, that uses the SIP or 
BICC/ISUP protocol (without the term "network", it simply refers to the protocol) 

inopportune: specifies a test purpose covering a signalling procedure where an inopportune message (type of message 
not expected in the lUT current state) is sent to the lUT 

Outgoing Interworking Unit (O-IWU): physical entity, (which can be combined with a BICC ISN or ISUP exchange) 
that terminates incoming calls using BICC or ISUP protocols and originates outgoing calls using the SIP 
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outgoing SIP or BICC/ISUP (network): network, to which the outgoing calls are sent, that uses the SIP or 
BICC/ISDN protocol 

NOTE: Without the term "network", it simply refers to the protocol. 

SIP precondition: indicates the support of the SIP "precondition procedure" 

NOTE: as defined in RFC 33 12 [6] . 

syntactically invalid: specifies a test purpose covering a signalling procedure where a valid (expected in the current 
status of the lUT) but not correctly encoded (unknown or incorrect parameter values) message is sent to the lUT, which 
reacts correctly and eventually reject the message 

test purpose: non-formal test description, mainly using text 

NOTE: TSIs test description can be used as the basis for a formal test specification (e.g. Abstract Test Suite in 
TTCN). See ISO/IEC 9646 [i.2]. 

valid: specifies a test purpose covering a signalling procedure where all the messages sent to or received from the lUT 
are valid (expected in the current status of the lUT) and correctly encoded 

3.1 .1 Conventions for representation of SIP/SDP information 

1) All letters of SIP method names are capitalized. 
EXAMPLE 1 : INVITE, INFO. 

2) SIP header fields are identified by the unabbreviated header field name as defined in the relevant RFC, 
including capitalization and enclosed hyphens but excluding the following colon. 

EXAMPLE 2: To, From, Call-ID. 

3) Where it is necessary to refer with finer granularity to components of a SIP message, the component concerned 
is identified by the ABNF rule name used to designate it in the defining RFC (generally 25/RFC 3261 [4]), in 
plain text without surrounding angle brackets. 

EXAMPLE 3: Request-URI, the user info portion of a sip: URL 

4) URI types are represented by the lower-case type identifier followed by a colon and the abbreviation "URI" 
EXAMPLE 4: sip: URI, tel: URI. 

5) SIP provisional responses and final responses other than 2XX are represented by the status code followed by 
the normal reason phrase for that status code, with initial letters capitalized. 

EXAMPLE 5 : 1 00 Trying, 484 Address Incomplete. 

6) Because of potential ambiguity within a call flow about which request a 200 OK final response answers, 200 
OK is always followed by the method name of the request. 

EXAMPLE 6: 200 OK INVITE, 200 OK PRACK. 

7) A particular line of an SDP session description is identified by the two initial characters of the line ~ that is, 
the line type character followed by "=" 

EXAMPLE 7: m=Hne, a=line. 

8) Where it is necessary to refer with finer granularity to components of a session description, the component 
concerned is identified by its rule name in the ABNF description of the SDP line concerned, delimited with 
angle brackets. 

EXAMPLE 8: the <media> and <fmt> components of the m= line. 



ETSI 



10 



ETSI TS 101 585 VI .1.2 (2012-09) 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 



ACR 

CB 

CFB 

CCBS 

CCNR 

CD 

CDIV 

CDP 

CDR 

CFNL 

CFNR 

CFU 

CONF 

CUG 

CW 

ECT 

GW 

HOLD 

ISDN 

lUT 

MCID 

MWI 

OIP 

OIR 

PASP 

PICS 

PSTN 

QoS 

SIP 

TIP 

TIR 

TP 

TSS 



Anonymous Communication Rejection 

Communication Barring 

Communication Forwarding Busy 

Completion of Communications to Busy Subscriber 

Completion of Communications by No Reply 

Communication Deflection 

Communication Diversion 

Charging Determinating Point 

Communication Data Record 

Communication Forwarding Not Logged in 

Communication Forwarding No Reply 

Communication Forwarding Unconditional 

Conference 

Closed User Group 

Communication Waiting 

Explicit Communication Transfer 

GateWay 

Communication Hold 

Integrated Services Digital Network 

Implementation Under Test 

Malicious Communication Identification 

Message Waiting Indication 

Originating Identification Presentation 

Originating Identification presentation Restriction 

Public Answering Safety Point 

Protocol Implementation Conformance Statement 

Public Switched Telephone Network 

Quality of service 

Session Initiation Protocol 

Terminating Identification Presentation 

Terminating Identification Restriction 

Test Purpose 

Test Suite Structure 
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Test Suite Structure (TSS) 



BCALL 



SIP-SIP 



successful 



SS bcall XXX 



Codec_Negotiation 



SS codec XXX 



Resource Reservation SS resource xxx 



unsuccessful 



SS unsucc xxx 



Service 



OIP 



OIR 



SS_oip_xxx 



SS oir xxx 



TIP 



SS_tip_xxx 



TIR 



SS tir xxx 



HOLD 



SS hold xxx 



CPU 



SS cfu xxx 



CFB 



SS cfb xxx 



CFNR 



SS cfnr xxx 



CFNL 



SS cfnl xxx 



CD 



SS cd xxx 



CONF 



SS conf xxx 



ACR-CB 



SS acr-cb xxx 



CUG 



CW 



SS_cug_xxx 



SS CW xxx 



ECT 



SS ect xxx 



MCID 



SS mcid xxx 



MWI 



SS mwi xxx 



CC 



SS CC xxx 



SIP-I 


uus 


SS uus xxx 


SUB 


SS sub xxx 


TP 


SS_tp_xxx 



NubP 


SS NP xxx 




lACCOUNTING 


SS ace xxx 




ics 


SS csel xxx 




|EmC 


SS_ecall_xxx 




SIP_charging 


SS_sipc_xxx 




SIP-SIP/QoS 


SS qos xxx 



Declarations 



5.1 

FFS 



Numbering Scheme 



5.2 Reference configuration 



This reference configuration depicted in figure 5.2-1 shall be used to perform an interconnection test between two 
network operators. Here is depicted the reference point to observe the message flow at the Tc' interface between the two 
networks (in the Testpurposes mentioned Interconnection Interface') one for a single operator and the possible set of 
end devices used to perform the Test Purposes. 
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SIP 


Network A 






Ic 


DSS1 




IBCFA 


^-^^ 






i\ 


f 


POTS 




\ 1 


I 


GSM 




VoLTE 








PSTN 




















SIP 



DSS1 



POTS 



GSM 



VoLTE 



PSTN 



Figure 5.2-1 : Reference configuration for tlie interconnection test 



5.3 



Selection of End Devices 



With the specified Test Purposes in the present document, the compatibiHty between the interconnected networks and 
the used end devices in the relevant networks shall be assured. Each Test Purpose shall be performed by using a 
physical end device to assure the end-to-end compatibility between the two interconnected networks. This is strictly 
recommended due to the fact that the impact from a end device to another end device is important and will marginal 
compensated by the network. 

Which Test Purposes are possible to perform depends on the types of end devices is used in the relevant network. The 
table 5.3-1 gives an overview of the end devices used in the relevant networks. The test staff of the network operator 
decides which type of end device is applicable for the test phase. 

The greeS highlighted element in the table represents the mandatory type of end devices used in the test. 

The yellow highlighted elements in the table represents the optional type of end devices used in the test. 

Table 5.3-1 : Used end devices in the relevant network 



Type of 
End devices 


Network B 


Network A 


SIP 


POTS 


ISDN 


GSM 


VoLTE 


PSTN 




SIP 
















POTS 
















ISDN 
















GSM 
















VoLTE 
















PSTN 
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Selection Expressions 



Table 6-1 is used to select the optional Test Purposes for the compatibly test between network operator A and network 
operator B. The decision whether a Selection Expression id fulfilled is basically agreed regarding the role of the 
network in the test. 

• Network operator 1 is in the role of Network A, Network operator 2 is in the role of Network B. 
In case of Repeat this test in reverse direction, mentioned in the Comment line in the Test Purpose. 

• Network operator 2 is in the role of Network A, Network operator 1 is in the role of Network B. 

In each Test Purpose is determined in the field SELECTION EXPRESSION whether the selection expression applies 
and the Test Purpose shall be performed. It has to be decided in which role the Test purpose is applicable (Support 
Network A, Support Network B). 

Before start of test, the table shall be filled out (yes/no) due to the operators gives an answer to the questions in 
table 6-1. This table can be used as a PICS form as used in a conformance test. 

Table 6-1 : Selection expression applicable in the Test Purposes 



SELECTION EXPRESSION: 


Support 


Support 




Network A 


Network B 


Network capabilities 


SE 1 : The originating network (Network A) sends the P-Charging-Vector 
header 






SE 2: The originating network (Network A) sends a subset of parameters in 
the P-Charging-Vector header 






SE3 


The P-Early-Media header is supported 






SE4 


Overlap procedure using multiple INVITE method is supported 






SE5 


Overlap sending using in-dialog method is supported 






SE6 


Network A supports the PSTN XML schema? 






SE7 


The resource reservation procedure is supported? 






SE8 


The Number Portability is supported? 






SE9 


The network is untrusted? 






SE 10: Originating network does not have a number portability data base, the 
number portability look up is done in the interconnected network? 






SE 1 1 : The network supports the REFER method? 






SE 12: The Network supports the 3 party call control procedure (REFER 
interworking)? 






SE 13: The Number Portability is supported? 






SE 14: Carrier Selection is performed? 






SE 15: The Network is a Long distance carrier (Verbindungsnetzbetreiber - 
VNB) 






SE 16: SIP Support of Charging is supported? 






SE 17: The interworking ISUP - SIP 1 is performed in the network 






Supplementary services 


SE 18: The network supports the Originating Identification Presentation 
(OIP)? 






SE 19: The network supports the "Special arrangement" procedure for the 
originating user? 






SE 20: The network supports the Originating Identification Restriction (OIR)? 






SE 21 : The Network supports the Terminating Identification Presentation 
(TIP)? 






SE 22: The network supports the "Special arrangement" procedure for the 
terminating user? 






SE 23: The Network supports the Terminating Identification Restriction (TIR)? 






SE 24: The Network supports the session HOLD procedure? 






SE 25: The network supports Communication Forwarding Unconditional 
(CFU)? 






SE 26: The network supports Communication Forwarding Busy (CFB)? 






SE 27: The network supports Communication Forwarding No Reply (CFNR)? 






SE 28: The Network supports Communication Forwarding Not Logged in 
(CFNL) 
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SELECTION EXPRESSION: 


Support 


Support 




Networl< A 


Networl< B 


SE29 


The Network supports Communication Deflection? 






SE30 


The Network supports the CDIV Notification procedure? 






SE31 


The Network supports conference (CONF) 






SE32 


The Network supports the Communication Barring procedure (CB) - 
(Black list for incoming calls)? 






SE 33: The Network supports the Anonymous Communication Rejection 
(ACR)? 






SE34 


The Network supports the Closed User Group (CUG)? 






SE35 


The Network supports the Communication Waiting (CW) service? 






SE36 


The Network supports the Tas-cw timer? 






SE37 


The Network supports Explicit Communication Transfer (ECT)? 






SE38 


The network supports Malicious Communication Identification (MCID) 






SE39 


The Network supports Message Waiting Indication (MWI)? 






SE40 


The Network supports Completion of Communications to Busy 
Subscriber (CCBS)? 






SE 41 : The Network supports Completion of Communications by No Reply 
(CCNR) 






Terminal capabilities 


SE 42: The End device (in Network B) establishes an Early dialogue by 

sending a 183 AND The Network B allows the bearer transmission in 
the early dialogue 






SE43 


The End device supports Fax transmission via G.71 1 codec 






SE44 


The End device supports Fax transmission via V.152 codec 






SE45 


The End device supports Fax transmission via m-line T.38 codec 






SE46 


A SIP end device is used supporting a ISDN user equipment and the 
PSTN XML Schema is used 






SE 47: End device is located in the PSTN or PLMN 






SE 48: The terminating UE supports the from-change tag procedure and 
sends a second user identity in an UPDATE request after the 
dialogue is confirmed 






SE49 


The end device performs ECT using the 'Blind/assured transfer' 






SE50 


The end device performs ECT using the 'Consultative transfer' 






SE51 


The end device supports the Resource reservation procedure 






PSTN/PLMN Supplementary services 


SE52 


CLIP/CLIR is supported in the PSTN/PLMN part of the network 






SE53 


COLP/COLR is supported in the PSTN/PLMN part of the network 






SE54 


HOLD is supported in the PSTN/PLMN part of the network 






SE 55 


CDIV is supported in the PSTN/PLMN part of the network 






SE56 


C0NF/3PTY is supported in the PSTN/PLMN part of the network 






SE57 


ACR is supported in the PSTN/PLMN part of the network 






SE58 


CUG is supported in the PSTN/PLMN part of the network 






SE59 


CW is supported in the PSTN/PLMN part of the network 






SE60 


ECT is supported in the PSTN/PLMN part of the network 






SE61 


MCID is supported in the PSTN/PLMN part of the network 






SE62 


SUB is supported in the PSTN/PLMN part of the network 






SE63 


UUS is supported in the PSTN/PLMN part of the network 






SE64 


TP is supported in the PSTN/PLMN part of the network 







Test purposes 



The application usage procedures in the ATS shall be compHant to TS 129 165 [1], TS 124 229 [2] and RFC 3261 [4]. 
The validation of the registration procedure is out of scope of the present document. 

The preconditions mechanism shall be supported by the UE in case of supporting IMS. 
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7.1 Testing of SIP protocol requirements 
7.1 .1 Test purposes for Basic call, Successful 



Test case number 


88 bcall 001 


Test case group 


BGALL/successful 


Reference 


[41 


SELECTION EXPRESSION 




Test purpose 


Basic call normal call clearing from the called user. 

Ensure that call establishment is performed correctly. In the active call state 
ensure the property of speech. The call is released from the called user. 


Configuration 




SIP Parameter 




Message flow 


SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 100 Trying 
^ 180 Ringing 
^ 200 OK INVITE 

ACK ^ 
Communication 

200 OK BYE ^ 


Comments 


Establish a communication from network A to Network B 

Check: Ensure the property of speech. 

Check: Are the media streams terminated after the 200 OK BYE was sent? 

Repeat this test in reverse direction. 

Repeat this test with all chosen end devices. 



Test case number 


88 bcall 002 


Test case group 


BCALL/successful 


Reference 


[4] 


SELECTION EXPRESSION 




Test purpose 


Basic call normal call clearing from the calling user. 

Ensure that call establishment is performed correctly. In the active call state 
ensure the property of speech. The call is released from the calling user. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
4- 100 Trying 
^ 180 Ringing 
^ 200 OK INVITE 

ACK ^ 
Communication 

^ 200 OK BYE 


Comments 


Establish a communication from network A to Network B 

Check: Ensure the property of speech. 

Check: Are the media streams terminated after the 200 OK BYE was sent? 

Repeat this test in reverse direction. 

Repeat this test with all chosen end devices. 
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Test case number 


SS bcall 003 


Test case group 


BCALL/successful 


Reference 


8/f1l 


SELECTION EXPRESSION 




Test purpose 


Request line in the INVITE. 

Ensure that the Request line in the INVITE contains in the userpart the 
telephone number of the destination user equipment formatted as a 'tel' URI in 
the global number format and the host portion is set to the host name of the 
interconnected network. The user URI parameter is present set to 'phone'. 


Configuration 




SIP Parameter 


INVITE 

Request line Address of user B @ network B;user=phone 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 

Apply post test routine 


Comments 


Establish a communication from network A to Network B 

Check: The userpart is in the format of a tel URI in global number format. 

Check: The hostportion is set to the host name of the interconnected network. 

Check: The user parameter is set to phone. 

Repeat this test in reverse direction. 

Repeat this test with all chosen end devices. 



Test case number 


SS bcall 004 


Test case group 


BCALL/successful 


Reference 


5.10/[2] 


Testspec Reference 




SELECTION EXPRESSION 


SE1 


Test purpose 


P-Charging-Vector header in the INVITE. 

Ensure that the P-Charging-Vector header is present in the INVITE establishes a 
communication between a user of network A and a user of network B and the 
'icid-value' and the 'orig-ioi' parameter is present. 


Configuration 




SIP Parameter 


INVITE 

P-Charging-Vector: icid-value; orig-ioi 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 
Check: The P-Charging-Vector header contains the icid-value parameter. 
Check: The P-Charging-Vector header contains the orig-ioi parameter. 
Repeat this test in reverse direction. 
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Test case number 


SS bcall 005 


Test case group 


BCALL/successful 


Reference 


5.10/[2] 


Testspec Reference 




SELECTION EXPRESSION 


SE2 


Test purpose 


P-Charging-Vector header in the INVITE. 

Ensure that the P-Charging-Vector header is present in the INVITE establishes a 
communication between a user of network A and a user of network B and the 
'icid-value' or the 'orig-ioi' parameter is present. 


Configuration 




SIP Parameter 


INVITE 

P-Charging-Vector: icid-value; orig-ioi 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 

Check: The P-Charging-Vector header contains the icid-value parameter 

(optional). 
Check: The P-Charging-Vector header contains the orig-ioi parameter 

(optional). 
Repeat this test in reverse direction. 



Test case number 


SS bcall 006 


Test case group 


BCALL/successful 


Reference 


8/[21] 


SELECTION EXPRESSION 


[Network A] SE 3 


Test purpose 


P-Early-Media header support indication in the initial INVITE request. 

Ensure that the support of the P-Early.Media header is indicated in the initial 
INVITE request. A P-Early-Media header is present set to 'supported'. 


Configuration 




SIP Parameter 


INVITE 

P-Early-Media: supported 
SDP 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 

Check: Is a P-Early-Media header is present in the INVITE request? 

Repeat this test in reverse direction. 



ETSI 



18 



ETSI TS 101 585 VI .1.2 (2012-09) 



Test case number 


SS bcall 007 


Test case group 


BCALL/successful 


Reference 


8/[21l 


SELECTION EXPRESSION 


[Network A] SE 3 AND [Network B] SE3 AND SE 42 


Test purpose 


P-Early-Media header supported early dialogue with 183. 

Ensure that an early dialogue is established by sending a 183 Session Progress 
from Network B and the P-Early-Media header is present authorizes early media. 


Configuration 




SIP Parameter 


INVITE 

P-Early-Media: supported 
SDP 

183 

P-Early-Media: [any value authorizes early media] 
SDP 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 183 Session Progress 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 
Check: Is a 1 83 sent from Network B to establish an early dialogue? 
Check: A bearer transmission is possible in backward directions. 
Repeat this test in reverse direction. 



Test case number 


SS bcall 008 


Test case group 


BCALL/successful 


Reference 


8/[21] 


SELECTION EXPRESSION 


[Network A] SE 3 AND [Network B] SE 3 


Test purpose 


P-Early-Media header supported early dialogue with 180. 

Ensure that an early dialogue is established by sending a 180 Ringing from 
Network B and the P-Early-Media header is present authorizes early media. 


Configuration 




SIP Parameter 


INVITE 

P-Early-Media: supported 
SDP 

180 

P-Early-Media: [any value authorizes early media] 
SDP 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 180 Ringing 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 
Check: Is a 1 83 sent from Network B to establish an early dialogue? 
Check: A bearer transmission is possible in backward directions. 
Repeat this test in reverse direction. 
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Test case number 


SS bcall 009 


Test case group 


BCALL/successful 


Reference 


8/f21l 


SELECTION EXPRESSION 


[Network A] SE 3 AND [Network B] SE 3 AND SE 25 AND SE 30 


Test purpose 


P-Early-Media header supported early dialogue with 181. 

Ensure that an early dialogue is established by sending a 181 Call Is Being 
Forwarded from Network B and the P-Early-Media header is present authorizes 
early media. The Call is forwarded in network B. 


Configuration 


Subscription options: 


• Originating user receives notification that his communication has been 
diverted = Yes 


SIP Parameter 


INVITE 

P-Early-Media: supported 
SDP 

181 

P-Early-Media: [any valu authorizes early media] 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 180 Call Is Being Forwarded 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 

Check: Is a 181 sent from Network B to establish an early dialogue? 

Repeat this test in reverse direction. 



Test case number 


SS bcall 010 


Test case group 


BCALL/successful 


Reference 


8/[21] 


SELECTION EXPRESSION 


[Network A] SE 3 AND [Network B] SE 3 AND SE 35 


Test purpose 


P-Early-Media header supported early dialogue with 182. 

Ensure that an early dialogue is established by sending a 182 Queued from 
Network B and the P-Early-Media header is present authorizes early media. The 
Call is a waiting call in network B. 


Configuration 




SIP Parameter 


INVITE 

P-Early-Media: supported 
SDP 

182 

P-Early-Media: [any value authorizes early media] 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 180 Call Is Being Forwarded 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 

Check: Is a 181 sent from Network B to establish an early dialogue? 

Repeat this test in reverse direction. 
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Test case number 


SS bcall 011 


Test case group 


BCALL/successful 


Reference 


5.10/[2] 


SELECTION EXPRESSION 




Test purpose 


Record-route header in the INVITE. 

Ensure that the Via header is present in the INVITE establishes a 
communication between a user of network A and a user of network B and the 
topmost header is set to the IBCF of network A. 


Configuration 




SIP Parameter 


INVITE 

Record-Route: <Address of IBCF in network A> 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 

Check: The topmost Record-Route header or entry contains the address of 

the IBCF of network A. 
Repeat this test in reverse direction. 
Repeat this test with all chosen end devices. 



Test case number 


SS bcall 012 


Test case group 


BCALL/successful 


Reference 


5.10/[21 


SELECTION EXPRESSION 




Test purpose 


Via header in the INVITE. 

Ensure that the Via header is present in the INVITE establishes a 
communication between a user of network A and a user of network B and the 
topmost header is set to the IBCF of network A and contains a branch 
parameter. 


Configuration 




SIP Parameter 


INVITE 

Via: <Address of IBCF in network A>; branch=[any value] 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 

Check: The topmost Via header contains the Address of IBCF in network A 

and a branch parameter. 
Repeat this test in reverse direction. 
Repeat this test with all chosen end devices. 
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Test case number 


SS bcall 013 


Test case group 


BCALL/successful 


Reference 


5.10/[2] 


SELECTION EXPRESSION 




Test purpose 


Record-Route header in the 180 Ringing. 

Ensure that the Record-Route header is present in the 180 Ringing provisional 
response as the first response from network B upon a connection establish setup 
from network A. 


Configuration 




SIP Parameter 


180: 

Record-Route 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
4- 180 Ringing 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 

Check: The Record-Route header is present is present in the 180 Ringing. 

Repeat this test in reverse direction. 

Repeat this test with all chosen end devices. 



Test case number 


SS bcall 014 


Test case group 


BCALL/successful 


Reference 


5.10/[21 


SELECTION EXPRESSION 




Test purpose 


Route header in the BYE of the originating user. 

Ensure that the Route header is present in the BYE request sent from the 
originating user equipment in network A and the topmost Route header or entry 
is set to the IBCF of network B. 


Configuration 




SIP Parameter 


BYE: 

Route: <Address of IBCF in network B>;lr, .... 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

A confirmed session already exists 
BYE ^ 
^ 200 OK BYE 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 

Check: The Route header is present is present in the BYE and the topmost 

header or entry is set to the address of the IBCF of network B. 
Repeat this test in reverse direction. 
Repeat this test with all chosen end devices. 
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Test case number 


SS bcall 015 


Test case group 


BCALL/successful 


Reference 


5.10/[2] 


SELECTION EXPRESSION 




Test purpose 


Route header in the BYE of the terminating user. 

Ensure that the Route header is present in the BYE request sent from the 
terminating user equipment in network B and the topmost Route header or entry 
is set to the IBCF of network A. 


Configuration 




SIP Parameter 


BYE: 

Route: <Address of IBCF in network A>;lr, .... 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

A confirmed session already exists 
^ BYE 

200 OK BYE ^ 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 

Check: The Route header is present is present in the BYE and the topmost 

header or entry is set to the address of the IBCF of network A. 
Repeat this test in reverse direction. 
Repeat this test with all chosen end devices. 



Test case number 


SS bcall 016 


Test case group 


BCALL/successful 


Reference 


5.10/[2] 


SELECTION EXPRESSION 




Test purpose 


Route header in the ACK. 

Ensure that the Route header is present in ACK from network A upon a 
connection establishment from network A is completed and the topmost Route 
header or entry is set to the IBCF of network B. 


Configuration 




SIP Parameter 


ACK: 

Route: <Address of IBCF in network B>;lr, .... 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 180 Ringing 
^ 200 OK INVITE 

ACK ^ 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 

Check: Route header is present is present in the ACK and the topmost header 

or entry is set to the address of the IBCF of network B. 
Repeat this test in reverse direction. 
Repeat this test with all chosen end devices. 
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Test case number 


SS bcall 017 


Test case group 


BCALL/successful 


Reference 


[41 and [5] 


SELECTION EXPRESSION 




Test purpose 


Handling of SDP parameters in the INVITE. 

Ensure that call establishment and the correct handling of the SDP parameters 
of the INVITE message defined as: TYPE_SDP is performed correctly. Ensure 
that in the active call state the voice/data transfer on the media channels is 
performed correctly (e.g. testing QoS parameters). In case when the parameter 
in the SDP rtpmap:<dynamic-PT> is used the codecs in table 7.1.1-1 applies. 


Configuration 




SIP Parameter 


INVITE: 

Content-Type: application/sdp 

m=audio <Port number> RTP/AVP TYPE_SDP= PIXIT (table 7.1.1-1) 

or 

m= Image <Port number> UdptI or TcptI TYPE SDP= PIXIT (table 7.1.1-1) 

a=TYPE SDP= PIXIT (table 1) 

b=TYPE SDP= PIXIT (table 1) 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 

Check: Is the preferred codec set to TYPE_SDP? 

Check: If present: is the a line set to TYPE_SDP? 

Check: If present: is the b line set to TYPE_SDP? 

Check: Is the codec list consistent with the attribute(s) (bandwidth) regarding 

the media description? 
Repeat this test in reverse direction. 
Repeat this test with all chosen end devices. 



Test case number 


SS bcall 018 


Test case group 


BCALL/successful 


Reference 


[4] and [5] 


SELECTION EXPRESSION 




Test purpose 


The SDP answer is sent in the 200 OK. 

Ensure that the call establishment performed correctly. 

The initial INVITE contains a SDP with the offer 1 according table 7.1.1-1. 

Ensure that answer related to the SDP offer is contained in the 200 OK INVITE 

message. 

Ensure that in the confirmed state the voice transfer on the media and B- 

channels is performed correctly. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE (SDP1) ^ 
^ 180 Ringing 
^ 200 OK INVITE (SDP2) 

ACK ^ 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 
Check: Is the SDP answer contained in the 200 OK INVITE. 
Repeat this test in reverse direction. 
Repeat this test with all chosen end devices. 
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Test case number 


SS bcall 018 


Test case group 


BCALL/successful 


Reference 


[41 and [5] 


SELECTION EXPRESSION 




Test purpose 


First response 200 OK INVITE. 


200 OK message. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
A 200 OK INVITE 

ACK ^ 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 
Check: Is it possible to confirm a session without early dialogue? 
Repeat this test in reverse direction. 
Repeat this test with all chosen end devices. 



Table 7.1 .1-1 



TYPE_SDP m= line 


b= line 


a= line 


VA 


<media> 


<transport> 


<fmt-list> 


<modifier>:<bandwidth- 

value> 

(see note) 


rtpmap:<dynamic-PT> <encoding 

name>/<clock rate>[/encoding 

parameters> 


VA 01 


Audio 


RTP/AVP 





N/A or up to 64 kbit/s 


N/A or rtpmap PCMU/8000 


VA 02 


Audio 


RTP/AVP 


Dynamic PT 


N/A or up to 64 kbit/s 


rtpmap:<dynamic-PT> PGMU/8000 


VA 03 


Audio 


RTP/AVP 


8 


N/A or up to 64 kbit/s 


N/A or rtpmap 8 PGMA/8000 


VA 04 


Audio 


RTP/AVP 


Dynamic PT 


N/A or up to 64 kbit/s 


rtpmap:<dynamic-PT> PGMA/8000 


VA 05 


audio 


RTP/AVP 


Dynamic PT 


N/A or up to 64 kbit/s 


rtpmap:<dynamic-PT> GLEARMODE 


NOTE: <bandwidth value> for <modifier> of AS is evaluated to be B kbit/s. 



Test case number 


SS bcall 020 


Test case group 


BGALL/successful 


Reference 


[4] and [5] 


SELECTION EXPRESSION 


[Network A] SE 43 AND [Network B] SE 43 


Test purpose 


Fax transmission using the G.711 codec. 

Ensure that a Fax transmission is possible from Network A to Network B and the 
relevant codec is the G.71 1 codec. Ensure in the active call state the property of 
Fax transmission. 


Configuration 




SIP Parameter 


INVITE: SDP 

m=audio <Port> RTP/AVP 8/0 
180/200 OK INVITE: SDP 

m=audio <Port> RTP/AVP 8 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE (SDP1) ^ 
^ 180 Ringing 
^ 200 OK INVITE (SDP2) 

AGK ^ 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 
Check: Is the SDP answer contained in the 200 OK INVITE. 
Check: is Fax transmission is successful? 
Repeat this test in reverse direction. 
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Test case number 


SS bcall 021 


Test case group 


BCALL/successful 


Reference 


[51 and [22] 


SELECTION EXPRESSION 


[Network A] SE 44 AND [Network A] SE 44 


Test purpose 


Fax transmission using the V.I 52 codec. 

Ensure that a Fax transmission is possible from Network A to Network B and the 
relevant codec is the V.I 52 codec. Ensure in the active call state the property of 
Fax transmission. 


Configuration 




SIP Parameter 


INVITE: SDP 

m=audio <Port> RTP/AVP 8 <dynamic-PT> 
a=rtpmap <dynamic-PT> PCMA/8000 
a=gpmd; vbd=yes 

T80/200 OK INVITE: SDP 

m=audio <Port> RTP/AVP <dynamic-PT> 
a=rtpmap <dynamic-PT> PCMA/8000 
a=gpmd; vbd=yes 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE (SDP1) ^ 
4- 180 Ringing 
^ 200 OK INVITE (SDP2) 

ACK ^ 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 

Check: Contains the SDP offer in the initial INVITE a voice band data codec. 

Check: contains the SDP answer in the 1 80 or 200 OK INVITE a voice band 

data codec. 
Check: Is Fax transmission is successful? 
Repeat this test in reverse direction. 



Test case number 


SS bcall 022 


Test case group 


BCALL/successful 


Reference 


[5] and [23] 


SELECTION EXPRESSION 


[Network A] SE 45 AND [Network B] SE 45 


Test purpose 


Fax transmission using the T.38 in an audio m-line codec. 

Ensure that a Fax transmission is possible from Network A to Network B and the 
relevant codec is the T.38 in an 'audio' m-line codec. Ensure in the active call 
state the property of Fax transmission. 


Configuration 




SIP Parameter 


INVITE: SDP 

m=image <Port> udpti t38 

180/200 OK INVITE: SDP 

m=image <Port> udptI t38 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE (SDP1) ^ 
4- 180 Ringing 
^ 200 OK INVITE (SDP2) 

ACK ^ 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 

Check: Contains the SDP offer in the initial INVITE a T.38 codec in an 'audio' 

line. 
Check: Contains the SDP answer in the 1 80 or 200 OK INVITE a T.38 codec 

in an 'audio' line. 
Check: Is Fax transmission is successful? 
Repeat this test in reverse direction. 
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Test case number 


SS bcall 023 


Test case group 


BCALL/successful 


Reference 


4.9, N/[21 


SELECTION EXPRESSION 


[Network A] SE 47 AND [Network A] SE 4 AND [Network B] SE 4 


Test purpose 


Overlap sending, the Multiple INVITE method is used. 

Ensure that call establishment using overlap sending is performed correctly. 
Ensure that in the confirmed state the voice transfer on the media and B-channels 
is performed correctly. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(CSql) ^ 

INVITE(CSq 2) ^ 
4- 484 Address lncomplete(CSq 1) 

ACK ^ 

INVITE(CSq 3) ^ 
^ 484 Address lncomplete(CSq 2) 

ACK ^ 

INVITE(CSq 4) ^ 
^ 484 Address lncomplete(CSq 3) 

ACK ^ 
^ 180 Ringing(CSq 4) 
Apply post test routine 


Comments 


Establish a communication from ISDN to SIP using the overlap operation in ISDN 
Check: All INVITE requests contains the same Call ID and From header 

values. 
SIP answers with 180 Ringing. 
Repeat this test in reverse direction. 
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Test case number 


SS bcall 024 


Test case group 


BGALL/successful 


Reference 


4.9, N/[21 


SELECTION EXPRESSION 


[Network A] SE 47 AND [Network A] SE 4 AND [Network B] SE 5 


Test purpose 


Overlap sending, the in-Dialogue method is used 

Ensure that call establishment using overlap sending is performed correctly. 
Ensure that in the confirmed state the voice transfer on the media and B-channels 
is performed correctly. 


Configuration 




SIP Parameter 


INVITE 2: 

Supported: lOOrel 

183: Require: lOOrel 

INFO: 

Content-Type: application/x-session-info 
SubsequentDigit: <additional digits> 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(CSq 1) 1 ^ 
^ 484 Address lncomplete(CSq 1 ) 

ACK ^ 

INVITE(CSq 2) 2 ^ 
^ 1 83 Session Progress(CSq 2) 

PRACK ^ 
^ 200 OK PRACK 

INFO ^ 
^ 200 OK INFO 

INFO ^ 
^ 200 OK INFO 

^ 180 Ringing(CSq 2) 

Apply post test routine 


Comments 


Establish a communication from ISDN to SIP using the overlap operation in ISDN 

Check: All INVITE requests contains the same Call ID and From header values. 

Check: The 183 session Progress that establishes an early dialogue contains a 
Require header set to lOOrel. 

Check: All INFO requests contain the Content-Type header set to 'application/x- 
session-info'. 

Check: All INFO requests contains the 'SubsequentDigit:' MIME body containing 
the additional digits. 

The UE B answers with 180 Ringing response after the INVITE was received. 

Repeat this test in reverse direction. 
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Test case number 


SS bcall 025 


Test case group 


BCALL/successful 


Reference 


5.1.1.1.2/[25] 


SELECTION EXPRESSION 


[Network A] (SE 46 OR SE 47) AND [Network A] SE 6 


Test purpose 


PSTN XML BearerCapability element in the INVITE. 

User A is located in network A and an ISDN end device is used. Ensure that the 
INVITE request contains a PSTN XML MIME body and a BearerCapability 
element as indicated in table 7.1.1-2 is present. 


Configuration 


User A is an ISDN access either in the PSTN or the SIP - ISDN interworking 
according [10] applies 


SIP Parameter 


INVITE: 

Content-Type: application/vnd.etsi.pstn+xml 
Content-Disposition: signal;handling=optional 

<?xml version="1.0" encoding="utf-8"?> 
PSTN 

BearerCapability 
BCoctetS 

CodingStandard>00< 
lnformationTransferCabability>ITC_valui< 
< BCoctet4 

TransferMode>00< 
lnformationTransferRate>1 0000< 
BCoctetS 

Layerl ldentification>01 < 
UserlnfoLayerl Protocol>0001 1 < 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
Apply post test routine 


Comments 


Check: Is a PSTN XML MIME body contained in the INVITE request? 

Check: Is the BearerCapability element is present? 

Check: Is InformationTransferCabability element is set as indicated in 

table 2.1.1-1? 
Check: Is the InformationTransferCabability element value consistent with the 

codec list in the SDP? 
Check: Is the InformationTransferCabability element value consistent with the 

bandwidth information in the SDP? 
Repeat this test in reverse direction. 



Table 7.1.1-2: PSTN XML BearerCapability 



ITC value 


BC Information transfer capability 


XML InformationTransferCabability 


ITC VA 1 


Speech 


'00000' 


ITC VA 2 


3,1 kHz audio 


'10000' 


ITC VA 3 


unrestricted digital information 


'01000' 
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Test case number 


SS bcall 026 


Test case group 


BCALL/successful 


Reference 


5.1.1.1.2/[25] 


SELECTION EXPRESSION 


[Network A] (SE 46 OR SE 47) AND [Network A] SE 6 


Test purpose 


PSTN XML HighLayerCapability element in the INVITE. 

User A is located in network A and an ISDN end device is used. Ensure that the 
INVITE request contains a PSTN XML MIME body and a HighLayerCapability 
element is present. 


Configuration 


User A is an ISDN access either in the PSTN or the SIP - ISDN interworking 
according [10] applies 


SIP Parameter 


INVITE: 

Content-Type: application/vnd.etsi.pstn+xml 
Content-Disposition: signal;handling=optional 

<?xml version="1.0" encoding="utf-8"?> 
PSTN 

HighLayerCompatibility 
HLOctetS 

CodingStandard>00< 
lnterpretation>100< 
PresentationMethod>01 < 
HL0ctet4 

HighLayerCharacteristics>[any value]< 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
Apply post test routine 


Comments 


Check: Is a PSTN XML MIME body contained in the INVITE request? 
Check: Is the HighLayerCapability element is present? 
Repeat this test in reverse direction. 
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Test case number 


SS bcall 027 


Test case group 


BCALL/successful 


Reference 


5.1.1.1.2/[25] 


SELECTION EXPRESSION 


[Network A] (SE 46 OR SE 47) AND [Network A] SE 6 


Test purpose 


PSTN XML Progresslndicator element in the INVITE. 

User A is located in network A and an ISDN end device is used. Ensure that the 
INVITE request contains a PSTN XIVIL IVIIIVIE body and at least one 
Progresslndicator element is present. 


Configuration 


User A is an ISDN access either in the PSTN or the SIP - ISDN interworking 
according [10] applies 


SIP Parameter 


INVITE: 

Content-Type: application/vnd.etsi.pstn+xml 
Content-Disposition: signal;handling=optional 

<?xml version="1.0" encoding="utf-8"?> 
PSTN 

Progresslndicator 
ProgressOctetS 

CodingStandard>00< 
Location>yyyy< 
ProgressOctet4 

ProgressDescription>000011 0< 
Progresslndicator 
ProgressOctetS 

CodingStandard>00< 
Location>0000< 
ProgressOctet4 

ProgressDescription>[any value]< 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
Apply post test routine 


Comments 


Check: Is a PSTN XML MIME body contained in the INVITE request? 
Check: Is a Progresslndicator element present and the ProgressDescription 

element is set to '0000110'? 
Check: Is optional a second Progresslndicator element present and the 

ProgressDescription element is set to any value not #2 and not #8? 
Repeat this test in reverse direction. 
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Test case number 


SS bcall 028 


Test case group 


BCALL/successful 


Reference 


5.1.2.2/[25] 


SELECTION EXPRESSION 


[Network B] (SE 46 OR SE 47) AND [Network B] SE 6 


Test purpose 


PSTN XML Progresslndicator element in the 180. 

User B is located in network B and an ISDN end device is used. Ensure that the 
180 Ringing response contains a PSTN XML MIME body and at least one 
Progresslndicator element is present. 


Configuration 


User B is an ISDN access either in the PSTN or the SIP - ISDN interworking 
according [10] applies 


SIP Parameter 


IgO: 

Content-Type: application/vnd.etsi.pstn+xml 
Content-Disposition: signal;handling=optional 

<?xml version="1.0" encoding="utf-8"?> 
PSTN 

Progresslndicator 
ProgressOctetS 

CodingStandard>00< 
Location>yyyy< 
ProgressOctet4 

ProgressDescription>00001 1 1< 
Progresslndicator 
ProgressOctetS 

CodingStandard>00< 
Location>0000< 
ProgressOctet4 

ProgressDescription>[any value]< 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 180 Ringing 
Apply post test routine 


Comments 


Check: Is a PSTN XML MIME body contained in the 180 Ringing response? 
Check: Is a Progresslndicator element present and the ProgressDescription 

element is set to '00001 10'? 
Check: Is optional a second Progresslndicator element present and the 

ProgressDescription element is set to any value not #2 and not #8? 
Repeat this test in reverse direction. 
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Test case number 


SS bcall 029 


Test case group 


BCALL/successful 


Reference 


5.1.2.3/[25] 


SELECTION EXPRESSION 


[Network B] (SE 46 OR SE 47) AND [Network B] SE 6 


Test purpose 


PSTN XML Progresslndicator element in the 200. 

User B is located in network B and an ISDN end device is used. Ensure that the 
200 OK INVITE response contains a PSTN XML MIME body and at least one 
Progresslndicator element is present. 


Configuration 


User B is an ISDN access either in the PSTN or the SIP - ISDN interworking 
according [10] applies 


SIP Parameter 


200: 

Content-Type: application/vnd.etsi.pstn+xml 
Content-Disposition: signal;handling=optional 

<?xml version="1.0" encoding="utf-8"?> 
PSTN 

Progresslndicator 
ProgressOctetS 

CodingStandard>00< 
Location>yyyy< 
ProgressOctet4 

ProgressDescription>00001 11 < 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 180 Ringing 
^ 200 OK INVITE 

ACK ^ 
Apply post test routine 


Comments 


Check: Is a PSTN XML MIME body contained in the 200 OK INVITE 

response? 
Check: Is a Progresslndicator element present and the ProgressDescription 

element is set to '00001 10'? 
Repeat this test in reverse direction. 
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Test case number 


SS bcall 030 


Test case group 


BCALL/successful 


Reference 


5.1.1.1.2/[25] 


SELECTION EXPRESSION 


[Network A] (SE 46 OR SE 47) AND [Network A] SE 6 


Test purpose 


PSTN XML BearerCapability Fallback connection type element in the 
INVITE. 

User A is located in network A and an ISDN end device is used. Ensure that the 
INVITE request contains a PSTN XIVIL IVIIIVIE body and one BearerCapability 
element is present the InformationTransferCabability element is set to '00000' 
and one InformationTransferCabability element is set to '10001'. 


Configuration 


User A is an ISDN access either in the PSTN or the SIP - ISDN interworking 
according [10] applies 


SIP Parameter 


INVITE: 

Content-Type: application/vnd.etsi.pstn+xml 
Content-Disposition: signal;handling=optional 

<?xml version="1.0" encoding="utf-8"?> 
PSTN 

BearerCapability 
BCoctetS 

CodingStandard>00< 
lnformationTransferCabability>00000< 
BearerCapability 
BCoctetS 

CodingStandard>00< 
lnformationTransferCabability>1 0001 < 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
Apply post test routine 


Comments 


Check: Is a PSTN XML MIME body contained in the INVITE request? 
Check: Is the first BearerCapability InformationTransferCabability element is 

set as indicated to '00000'? 
Check: Is the second BearerCapability InformationTransferCabability element 

is set as indicated to '10001'? 
Check: Is the InformationTransferCabability element value consistent with the 

codec list in the SDP? 
Check: Is the InformationTransferCabability element value consistent with the 

bandwidth information in the SDP? 
Repeat this test in reverse direction. 
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Test case number 


SS bcall 031 


Test case group 


BCALL/successful 


Reference 


5.1.2.3/[25] 


SELECTION EXPRESSION 


[Network B] (SE 46 OR SE 47) AND [Network B] SE 6 


Test purpose 


Fall back does not occur. 

User B is located in network B and an ISDN end device is used. The Fallback 
connection type was requested in the initial INVITE request. Ensure that the 200 
OK INVITE response contains a PSTN XML MIME body and a BearerCapability 
element is present the InformationTransferCabability element set to '10001'. 


Configuration 


User B is an ISDN access either in the PSTN or the SIP - ISDN interworking 
according [10] applies 


SIP Parameter 


200: 

Content-Type: application/vnd.etsi.pstn+xml 
Content-Disposition: signal;handling=optional 

<?xml version="1.0" encoding="utf-8"?> 
PSTN 

BearerCapability 
BCoctetS 

CodingStandard>00< 
lnformationTransferCabability>1 0001 < 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
4- 180 Ringing 
^ 200 OK INVITE 

ACK ^ 
Apply post test routine 


Comments 


Check: Is a PSTN XML MIME body contained in the 200 OK INVITE 

response? 
Check: Is a BearerCapability element present, the 

InformationTransferCabability element set to '10001'? 
Check: Is the InformationTransferCabability element value consistent with the 

codec list in the SDP? 
Check: Is the InformationTransferCabability element value consistent with the 

bandwidth information in the SDP? 
Repeat this test in reverse direction. 
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Test case number 


SS bcall 032 


Test case group 


BCALL/successful 


Reference 


5.1.2.3/[25] 


SELECTION EXPRESSION 


[Network B] (SE 46 OR SE 47) AND [Network B] SE 6 


Test purpose 


Fall back occurs. 

User B is located in network B and an ISDN end device is used. The Fallback 
connection type was requested in the initial INVITE request. Ensure that the 200 
OK INVITE response contains a PSTN XML MIME body and a BearerCapability 
element is present the InformationTransferCabability element set to '00000'. A 
PSTN XML MIME Progresslndicator body is present, the ProgressDescription is 
set to '0000101'. 


Configuration 


User B is an ISDN access either in the PSTN or the SIP - ISDN interworking 
according [10] applies 


SIP Parameter 


200: 

Content-Type: application/vnd.etsi.pstn+xml 
Content-Disposition: signal;handling=optional 

<?xml version="1 .0" encoding="utf-8"?> 
PSTN 

BearerCapability 
BCoctetS 

CodingStandard>00< 
lnformationTransferCabability>00000< 
Progresslndicator 
ProgressOctet4 

ProgressDescription>00001 01 < 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
4- 180 Ringing 
^ 200 OK INVITE 

ACK ^ 
Apply post test routine 


Comments 


Check: Is a PSTN XML MIME body contained in the 200 OK INVITE 

response? 
Check: Is a BearerCapability element present, the 

InformationTransferCabability element set to '00000'? 
Check: Is a Progresslndicator element is present, the ProgressDescription is 

set to '0000101'? 
Check: Is the InformationTransferCabability element value consistent with the 

codec list in the SDP? 
Check: Is the InformationTransferCabability element value consistent with the 

bandwidth information in the SDP? 
Repeat this test in reverse direction. 
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Test case number 


SS bcall 033 


Test case group 


BCALL/successful 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 


Test purpose 


SIP-I support, Basic call, lAM present in the INVITE request. 

Ensure that when a call initiated in the PSTN or the PLMN and the ISUP - 
SIP-I interworking is applicable in the originating network, a ISUP lAM is 
encapsulated in the initial INVITE request. 

Ensure that all the mandatory parameters in the lAM are present and the values 
are valid and the Transmission medium requirement parameter is consistent 
with the SDP. 


Configuration 




SIP Parameter 


INVITE: 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

lAM 

Nature of connection indicators 

Forward call indicators 

Calling party's category 

Transmission medium requirement 

Called party number 

Calling party number (optional) 

Optional forward call indicators (optional) 

Hop counter (optional) 

User service information (optional) 

Access transport (optional) 

-[any boundary name]- 


Message flow 


SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(IAM) ^ 
^ 100 Trying 

Apply post test routine 


Comments 


Establish a communication from network A to Network B 

Check: Is an ISUP lAM encapsulated in the INVITE request? 

Check: Are all the mandatory ISUP parameters present in the lAM and are the 

values valid? 
Check: Are the values of the optional parameters in the encapsulated lAM 

valid? 
Check: Is the 'm' line with corresponding attributes in the SDP consistent with 

the Transmission medium requirement parameter? 
Check: Is the Transmission medium requirement value consistent with the 

bandwidth information in the SDP? 
Repeat this test in reverse direction. 
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Test case number 


SS bcall 034 


Test case group 


BCALL/successful 


Reference 


7.2.1/[24] 


SELECTION EXPRESSION 


[Network A] SE 4 AND SE 1 7 AND SE 47 


Test purpose 


SIP-I support, Basic call, overlap signalling. 

Ensure that when overlap signalling applies in the ISUP -SIP-I interworking in the 
originating network, several INVITE requests with the same Cal-ID and From tag 
are sent from Network A to Network B. 
Ensure that the original lAM is encapsulated in any INVITE request. 


Configuration 




SIP Parameter 




Message flow 


SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(1) ^ 
4- 484 Address lncomplete(1 ) 

ACK ^ 
INVITE(2) ^ 
4- 484 Address lncomplete(2) 

ACK ^ 
INVITE(3) ^ 
4- 484 Address lncomplete(3) 

ACK ^ 

INVITE(4) ^ 
^ 180 Ringing(4) 

Apply post test routine 


Comments 


Establish a communication from network A to Network B using the overlap 
procedure in Network A 

Check: Are the INVITE requests sent with the same From tag and the Call-ID? 
Check: After the 180 applies, are all previous INVITE transactions are 

terminated with a 484 final response? 
Check: Is the encapsulated lAM present in the initial INVITE request also 

encapsulated in any following INVITE request required for the call 

setup? 
Repeat this test in reverse direction. 
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Test case number 


SS bcall 035 


Test case group 


BCALL/successful 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B]SE 17 AND SE 47 


Test purpose 


SIP-I support, Basic call, ACM present in the 180 response. 

Ensure that on receipt of a 180 Ringing provisional response and an 

SIP-I - ISUP interworking is applicable in the terminating network the Backward 

call indicators parameter in the encapsulated ACM is present and the values are 

valid. 

Ensure that the values of the optional parameters in the encapsulated ACM are 

valid. 


Configuration 




SIP Parameter 


180: 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

ACM 

Backward call indicators 

-[any boundary name]- 


Message flow 


SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 100 Trying 
^ 180Ringing(ACM) 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 

Check: Is an ISUP ACM message encapsulated in the 180 Ringing provisional 

response? 
Check: Is the mandatory Backward call indicators parameter present in the 

encapsulated ISUP ACM and are the values valid? 
Check: Are the values of optional parameters in the encapsulated ISUP ACM 

valid? 
Check: If an SDP answer is present in the 180, are the codec and the 

bandwidth information in the 'a' attributes consistent with Transmission 

medium requirement in the encapsulated lAM of the INVITE request? 
Repeat this test in reverse direction. 
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Test case number 


SS bcall 036 


Test case group 


BCALL/successful 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B]SE 17 AND SE 47 


Test purpose 


SIP-I support. Basic call, early ACM present in the 183 response. 

Ensure that on receipt of a 183 Session Progress provisional response and an 

SIP-I - ISUP interworking is applicable in the terminating network the Backward 

call indicators parameter in the encapsulated ACM is present and the value of 

the Called party's status indicator is set to no indication'. 

Ensure that the values of the optional parameters in the encapsulated ACM are 

valid. 


Configuration 


Select a proper destination that sends an early ACM in the PSTN/PLMN e.g. 
announcement 


SIP Parameter 


183: 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

ACM 

Backward call indicators 

Called party's status indicator= no indication 

-[any boundary name]- 


Message flow 


SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 100 Trying 
^ 1 83 Session Progress(ACI\/l) 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 

Check: Is an ISUP ACM message encapsulated in the 183 Session Progress 

provisional response? 
Check: Is the mandatory Backward call indicators parameter present in the 

encapsulated ISUP ACM and are the values valid? 
Check: Is the Called party's status indicator in the encapsulated ISUP ACM 

set to 'no indication'? 
Check: Are the values of optional parameters in the encapsulated ISUP ACM 

valid? 
Repeat this test in reverse direction. 
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Test case number 


SS bcall 037 


Test case group 


BCALL/successful 


Reference 


6.6/[24] 


SELECTION EXPRESSION 


[Network B]SE 17 AND SE 47 


Test purpose 


SIP-I support. Basic call, CPG present in a 180 response. 

Ensure that on receipt of a 180 Ringing provisional response and an 

SIP-I - ISUP interworking is applicable in the terminating network the Event 

indicator in the encapsulated CPG is present and set to 'ALERTING'. 

Ensure that the values of the optional parameters in the encapsulated CPG are 

valid. 


Configuration 


Select a proper destination that sends at first an early ACM and after then a 
CPG 'ALERTING' in the PSTN/PLMN (e.g. PBX). 


SIP Parameter 


180: 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

CPG 

Event indicator = ALERTING 

-[any boundary name]- 


Message flow 


SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 100 Trying 
^ 1 83 Session Progress(ACI\/l) 
^ 180 Ringing(CPG) 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 

Check: Is an ISUP CPG message encapsulated in the 180 Ringing provisional 

response? 
Check: Is the mandatory Event indicator present in the encapsulated ISUP 

CPG set to 'ALERTING'? 
Check: Are the values of optional parameters in the encapsulated ISUP CPG 

valid? 
Repeat this test in reverse direction. 



ETSI 



41 



ETSI TS 101 585 VI .1.2 (2012-09) 



Test case number 


SS bcall 038 


Test case group 


BCALL/successful 


Reference 


6.7/[24] 


SELECTION EXPRESSION 


[Network B]SE 17 AND SE 47 


Test purpose 


SIP-I support. Basic call, ANM present in a 200 OK INVITE response. 

Ensure that on receipt of a 200 OK INVITE final response and an SIP-I - ISUP 

interworking is applicable in the terminating network the ISUP ANM is 

encapsulated in the 200 OK. 

Ensure that the values of the optional parameters in the encapsulated ANM are 

valid. 


Configuration 




SIP Parameter 


180: 

Content-Type: multipart/mixed;boundary=[any boundary name] 

--[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

ANM 

-[any boundary name]- 


Message flow 


SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 100 Trying 
^ 180Ringing(ACM) 
^ 200 OK INVITE(ANM) 

ACK ^ 
Apply post test routine 


Comments 


Establish a confirmed communication from network A to Network B 

Check: Is an ISUP ANM encapsulated in the 200 OK INVITE? 

Check: Are the values of optional parameters in the encapsulated ISUP ANM 

valid? 
Check: Ensure the property of speech. 
Check: Are the codec and the bandwidth information in the 'a' attributes 

consistent with Transmission medium requirement in the encapsulated 

lAM of the INVITE request? 
Repeat this test in reverse direction. 
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Test case number 


SS bcall 039 


Test case group 


BCALL/successful 


Reference 


5.4.3.4, 6.11. 2/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 


Test purpose 


SIP-I support. Basic call, REL present in a BYE request sent from the 
originating network. 

Ensure that a ISUP REL message is encapsulated in a BYE request sent in the 

release procedure initiated from the originating user when ISUP - SIP-I 

interworking is applicable in the originating network. 

Ensure the validity of the cause indicator in the encapsulated REL. 

Ensure that the ISUP RLC is encapsulated in the 200 OK BYE. 


Configuration 




SIP Parameter 


BYE: 

Content-Type: multipart/mixed;boundary=[any boundary name] 

--[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

REL 

Cause value: 

-[any boundary name]- 

200 OK BYE 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

RLC 

-[any boundary name]- 


Message flow 


SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 100 Trying 
4- 180 Ringing 
^ 200 OK INVITE 

ACK ^ 
Communication 

BYE(REL) ^ 
^ 200 OK BYE(RLC) 


Comments 


Establish a confirmed communication from network A to Network B 

The originating user terminates the communication 

Check: Is the ISUP REL encapsulated in the BYE request? 

Check: Are the cause indicators in the encapsulated ISUP REL valid? 

Check: If a Reason header is present in the BYE request, is the 'cause' value 

of Reason header equal to the 'Cause value' in the encapsulated 

REL? 
Check: Is the ISUP RLC encapsulated in the 200 OK BYE? 
Repeat this test in reverse direction. 
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Test case number 


SS bcall 040 


Test case group 


BCALL/successful 


Reference 


5.4.3.4, 6.11. 2/[24] 


SELECTION EXPRESSION 


[Network B]SE 17 AND SE 47 


Test purpose 


SIP-I support. Basic call, REL present in a BYE request sent from the 
terminating network. 

Ensure that a ISUP REL message is encapsulated in a BYE request sent in the 

release procedure initiated from the terminating user when SIP-I - ISUP 

interworking is applicable in the terminating network. 

Ensure the validity of the cause indicator in the encapsulated REL. 

Ensure that the ISUP RLC is encapsulated in the 200 OK BYE. 


Configuration 




SIP Parameter 


BYE: 

Content-Type: multipart/mixed;boundary=[any boundary name] 

--[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

REL 

Cause value: 

-[any boundary name]- 

200 OK BYE 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

RLC 

-[any boundary name]- 


Message flow 


SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 100 Trying 
4- 180 Ringing 
^ 200 OK INVITE 

ACK ^ 
Communication 
^ BYE(REL) 

200 OK BYE(RLC) ^ 


Comments 


Establish a confirmed communication from network A to Network B 

The terminating user terminates the communication 

Check: Is the ISUP REL encapsulated in the BYE request? 

Check: Are the cause indicators in the encapsulated ISUP REL valid? 

Check: If a Reason header is present in the BYE request, is the 'cause' value 

of Reason header equal to the 'Cause value' in the encapsulated 

REL? 
Check: Is the ISUP RLC encapsulated in the 200 OK BYE? 
Repeat this test in reverse direction. 
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7. 1 .2 Codec negotiation 



Test case number 


SS codec 001 


Test case group 


BCALL/Codec Negotiation 


Reference 


[31, [41 and [51 


SELECTION EXPRESSION 




Test purpose 


Session update requested by the calling user. 

During the session, the calling user decides to change the characteristics of the 
media session. This is accomplished by sending a re-INVITE or UPDATE 
containing a new media description. This re-INVITE or UPDATE references the 
existing dialog so that the other party knows that it is to modify an existing 
session instead of establishing a new session. The other party sends a 200 (OK) 
to accept the change. The requestor responds to the 200 (OK) with an ACK. 
In case when the parameter in the SDP rtpmap:<dynamic-PT> is used the 
codecs in table 7.1 .2-1 applies. 


Configuration 




SIP Parameter 


SDP1 : codec x chosen from table 7.1 .2-1 
SDP3: codec y chosen from table 7.1 .2-1 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 
A confirmed session already exists (SDP 1) 
CASE A INVITE(SDP3) ^ 

■ 200 OK INVITE(SDP4) 

ACK ^ 

CASE B UPDATE(SDP3) ■ 

■ 200 OK UPDATE(SDP4) 

Apply post test routine 


Comments 


Establish a communication from network A to Network B using SDP1 chosen 

from the table 7.1.2-1 

Check: The calling user changes the media description using INVITE request 

containing SDP 3 codec chosen from table 7.1 .2-1 different to SDP1 . 
Check: Is the codec list consistent with the attribute(s) (bandwidth) regarding 

the media description? 
Repeat this test in reverse direction. 
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Test case number 


SS codec 002 


Test case group 


BCALL/Codec Negotiation 


Reference 


[31, [41 and [51 


SELECTION EXPRESSION 




Test purpose 


Session update requested by the called user. 

During the session, the called user decides to change the characteristics of the 
media session. This is accomplished by sending a re-INVITE containing a new 
media description. This re- INVITE references the existing dialog so that the 
other party knows that it is to modify an existing session instead of establishing a 
new session. The other party sends a 200 (OK) to accept the change. 
The requestor responds to the 200 (OK) with an ACK. 
In case when the parameter in the SDP rtpmap:<dynamic-PT> is used the 
codecs in table 7.1 .2-1 applies. 


Configuration 




SIP Parameter 


SDP1 : codec x chosen from table 7.1 .2-1 
SDP2: codec y chosen from table 7.1 .2-1 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 
A confirmed session already exists (SDP 1) 
CASE A INVITE(SDP3) ^ 

■ 200 OK INVITE(SDP4) 

ACK ^ 

CASE B UPDATE(SDP3) ^ 

■ 200 OK UPDATE(SDP4) 

Apply post test routine 


Comments 


Establish a connection from SIP UE 1 to SIP UE 2 using SDP1 chosen from the 

table 7.1.2-1 

Check: The called user changes the media description using INVITE request 

containing SDP 2 codec chosen from table 7.1 .2-1 different to SDP1 . 
Check: Is the codec list consistent with the attribute(s) (bandwidth) regarding 

the media description? 
Repeat this test in reverse direction. 



Test case number 


SS codec 003 


Test case group 


BCALL/Codec Negotiation 


Reference 


[31, [41 and [51 


SELECTION EXPRESSION 




Test purpose 


The SDP answer is contained in a 200 OK final response. 

Ensure that the call establishment performed correctly. 

• The initial INVITE contains a SDP with the offer 1 . 

• Ensure that answer related to the SDP offer is contained in the 200 
OK INVITE message. 

Ensure that in the confirmed call state the voice transfer on the media channels 
is performed correctly. 


Configuration 




SIP Parameter 


INVITE: SDP offer 
200: SDP answer 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(SDPI) ^ 
^ 180 Ringing 
^ 200 OK INVITE(SDP2) 

ACK ^ 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 
Check: Is the SDP offer contained in the initial INVITE request? 
Check: Is the SDP answer contained in the 200 OK INVITE final response? 
Repeat this test in reverse direction. 
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Table: 7.1.2-1 



VARIABLE 


PT 


Encoding 


media 
type 


clock 
rate 


channels 


Supported in 
network A 


Supported in 
network B 


VA 01 





PCMU 


A 


8,000 








VA 02 


3 


GSM 


A 


8,000 








VA 03 


4 


G723 


A 


8,000 








VA 04 


5 


DVI4 


A 


8,000 








VA 05 


6 


DVI4 


A 


16,000 








VA 06 


7 


LPC 


A 


8,000 








VA 07 


8 


PCMA 


A 


8,000 








VA 08 


9 


G722 


A 


8,000 








VA 09 


10 


L16 


A 


44,100 


2 






VA 10 


11 


L16 


A 


44,100 








VA 13 


12 


QCELP 


A 


8,000 








VA 12 


13 


CN 


A 


8,000 








VA 13 


14 


MPA 


A 


90,000 








VA 14 


15 


G728 


A 


1 8,000 








VA 15 


16 


DVI4 


A 


11,025 








VA 16 


17 


DVI4 


A 


22,050 








VA 17 


18 


G729 


A 


8,000 








VA 18 


Dyn 


G726-40 


A 


8,000 








VA 19 


Dyn 


G726-32 


A 


8,000 








VA 20 


Dyn 


G726-24 


A 


8,000 








VA 21 


Dyn 


G726-16 


A 


8,000 








VA 22 


Dyn 


G729D 


A 


8,000 








VA 23 


Dyn 


G729E 


A 


8,000 








VA 24 


Dyn 


GSM-EFR 


A 


8,000 








VA 25 


25 


CelB 


V 


90,000 








VA 26 


26 


JPEG 


V 


90,000 








VA 27 


28 


Nv 


V 


90,000 








VA 28 


31 


H261 


V 


90,000 








VA 29 


32 


MPV 


V 


90,000 








VA 30 


33 


MP2T 


V 


90,000 








VA 31 


34 


H263 


V 


90,000 








VA 32 


Dyn 


H263-1998 


V 


90,000 








VA 33 


Dyn 


AMR 


A 


8,000 


1 






VA 34 


Dyn 


AMR-WB 


A 


16,000 


1 






VA 35 


Dyn 


telephone- 
event 


A 


8000 


1 
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7.1 .3 Resource Reservation 



Test case number 


SS resource 001 


Test case group 


BCALL/Resource Reservation 


Reference 


[31, [41, [51 and [61 


SELECTION EXPRESSION 


([Network Al SE 50 AND [Network Bl SE 50) AND SE 7 


Test purpose 


Resource reservation successful, segmented status. 

Ensure that the network is able to reserve resources for quality of service when 
requested from the initiating user. 

• In the INVIT the UE requests to establish QoS preconditions for all the 
media streams. 

• In the 183 Session Progress the UAS supports the QoS preconditions 
and requests that UAC sends a confirmation when the QoS 
preconditions are met. 

• The UPDATE includes in the SDP the information about the successful 
QoS bidirectional mode, due to the successful bidirectional PDP context 
established. 

• 200 OK UPDATE the SDP contains an indication that the UE 
successfully reserved the QoS in the send and receive directions. 


Configuration 




SIP Parameter 


INVITE: Supported: lOOrel precondition 
SDP1 : m=audio 3456 RTP/AVP 8 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

183 Session Progress: Supported: lOOrel precondition 
SDP2: m=audio 6544 RTP/AVP 8 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

UPDATE 

SDP3: m=audio 3456 RTP/AVP 8 


|tcurr:qos local s'enSrlB 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos mandatory remote sendrecv 

200 OK UPDATE 

SDP4: a=curr:qos local sendrec^ 
a=curr:qos remote sendrecv 
a=des:qos mandatory local sendrecv 
a=des:qos mandatory remote sendrecv 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(SDPI) ^ 
^ 1 83 Session Progress(SDP2) 

PRACK ^ 
^ 200 OK PRACK 

Resource reservation 

ireATE(SDP3) ^ 
^ 200 OK UPDATE(SDP4) 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 

Check: Is the quality of service for the current state local and remote set to 

'none' indicated in the SDP in the INVITE? 
Check: Is the quality of service for the desired state local and remote set to 

'mandatory' and 'sendrecv' in the 183? 
Check: Is the quality of service for the current state local set to 'sendrecv' 

indicated in the SDP in the UPDATE? 
Check: Is the quality of service for the current state local and remote set to 

'sendrecv' indicated in the SDP in the 200 OK UPDATE? 
Repeat this test in reverse direction. 
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7.1 .4 Test purposes for SIP-SIP, Basic call, Unsuccessful 



Test case number 


SS unsuGG 001 


Test case group 


BGALL/unsuGGessful 


Reference 


[41 


SELECTION EXPRESSION 




Test purpose 


Called number is not allocated in the assumed network. 

Ensure that, when Galling to unalloGated number, the network initiate oall olearing 
to the Galling user with a 404 Not Found message. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 404 Not Found 

ACK ^ 


Comments 


Establish a Gommunioation from network A to Network B, Galled user number is 

not allooated in Network B 

Check: Is a 404 Not Found sent from Network B to Network A? 

Repeat this test in reverse direotion. 

Repeat this test with all ohosen end devioes. 



Test case number 


SS unsucc 002 


Test case group 


BCALL/unsuccessful 


Reference 


[41 


SELECTION EXPRESSION 




Test purpose 


The network B is unable to process the request. 

Ensure that the call will be released if the Service unavailable. The network 
initiates call clearing to the calling user with a 503 Service unavailable message. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 503 Servioe unavailable 

ACK ^ 


Comments 


Establish a communication from network A to Network B, Network B is unable to 

process the request. 

Check: Is a 503 Service unavailable sent from Network B to Network A? 

Repeat this test in reverse direction. 

Repeat this test with all chosen end devices. 



Test case number 


SS unsucc 003 


Test case group 


BCALL/unsuccessful 


Reference 


[41 


SELECTION EXPRESSION 




Test purpose 


The called user is network determined busy. 

Ensure that, when the called user is busy, the network initiates call clearing to 
the calling user with a 486 Busy Here message. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 486 Busy Here 

ACK ^ 


Comments 


Establish a communication from network A to Network B, user B is network 
determined user busy. 

Check: Is a 486 Busy Here sent from Network B to Network A? 
Repeat this test in reverse direction. 
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Test case number 


SS unsucc 004 


Test case group 


BCALL/unsuccessful 


Reference 


[41 


SELECTION EXPRESSION 




Test purpose 


The called user is user determined busy. 

Ensure that, when the called user is busy, the user initiates call clearing to the 
calling user with a 486 Busy Here message. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 486 Busy Here 

ACK ^ 


Comments 


Establish a communication from network A to Network B, user B is user 
determined user busy. 

Check: Is a 486 Busy Here sent from Network B to Network A 
Repeat this test in reverse direction. 



Test case number 


SS unsucc 005 


Test case group 


BCALL/unsuccessful 


Reference 


[41 


SELECTION EXPRESSION 




Test purpose 


The called user is not available under the called number. 

Ensure that when the number is changed, the network initiate call clearing 
to the calling user with a 410 Gone message. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 410 Gone 

ACK ^ 


Comments 


Establish a communication from network A to Network B, user B is not 
allocated in Network B. 

Check: Is a 41 Gone sent from Network B to Network A? 
Repeat this test in reverse direction. 



Test case number 


SS unsucc 006 


Test case group 


BCALL/unsuccessful 


Reference 


[41 


SELECTION EXPRESSION 




Test purpose 


The number of the called user is incomplete. 

Ensure that the call will be released when the called number is incomplete. The 
network initiates call clearing to the calling user with 484 Not Found message. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
4- 484 Address Incomplete 

ACK ^ 


Comments 


Establish a communication from network A to Network B, the called number is 

incomplete. 

Check: Is a 484 Address Incomplete sent from Network B to Network A? 

Repeat this test in reverse direction. 
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Test case number 


SS unsucc 007 


Test case group 


BGALL/unsuccessful 


Reference 


[31, [41 and [51 


SELECTION EXPRESSION 




Test purpose 


Session update requested by the calling user is unsuccessful, existing 
session remains unchanged. 

During the session, the calling user decides to change the characteristics of the 
media session. This is accomplished by sending a re-INVITE containing a new 
media description. This re-INVITE references the existing dialog so that the other 
party knows that it is to modify an existing session instead of establishing a new 
session. Ensure that if the other party does not accept the change, he sends an 
error response such as 488 Not Acceptable Here, which also receives an ACK. 
The session remains unchanged. 


Configuration 




SIP Parameter 


INVITE: codec not supported in Network B 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
4- 180 Ringing 
^ 200 OK INVITE 

ACK ^ 
Communication 

INVITE ^ 
^ 488 Not Acceptable Here 

ACK ^ 
Apply post test routine 


Comments 


Establish a communication from network A to Network B. 

User A in Network A attempts to change the session by sending a SDP offer to 

the UE in Network B. 

Network B does not support the codec sent in the offer. 

Check: Is a 488 Not Acceptable Here sent from Network B to Network A? 

Repeat this test in reverse direction. 
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Test case number 


SS unsucc 008 


Test case group 


BGALL/unsuccessful 


Reference 


[31, [41 and [51 


SELECTION EXPRESSION 




Test purpose 


Session update requested by the called user is unsuccessful, existing 
session remains unchanged. 

During the session, the called user decides to change the characteristics of the 
media session. This is accomplished by sending a re-INVITE containing a new 
media description. This re-INVITE references the existing dialog so that the other 
party knows that it is to modify an existing session instead of establishing a new 
session. Ensure that if the other party does not accept the change, he sends an 
error response such as 488 Not Acceptable Here, which also receives an ACK. 
The session remains unchanged. 
The 488 Not Acceptable Here may be sent by a simulation equipment. 


Configuration 




SIP Parameter 


INVITE: codec not supported in Network A 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 180 Ringing 
^ 200 OK INVITE 

ACK ^ 
Communication 
^ INVITE 

488 Not Acceptable Here ^ 
^ ACK 

Apply post test routine 


Comments 


Establish a communication from network A to Network B. 

User B in Network B attempts to change the session by sending a SDP offer to 

the UE in Network A 

Network A does not support the codec sent in the offer. 

Check: Is a 488 Not Acceptable Here sent from Network B to Network A? 

Repeat this test in reverse direction. 



Test case number 


SS unsucc 009 


Test case group 


BCALL/unsuccessful 


Reference 


[41 


SELECTION EXPRESSION 




Test purpose 


Call clearing due to no answer from the called user initiated by the calling 
user. 

Ensure that when there is no answer from the called user, the calling user 
initiates call clearing to the called user with CANCEL or BYE 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 180 Ringing 

CANCEL/BYE ^ 
^ 200 OK CANCEL/BYE 
4- 487 Request Terminated 

ACK ^ 


Comments 


Check: Is a CANCEL or BYE request is sent from the originating user? 
Check: Is a 487 Request Terminating send from the terminating user? 
Check: Are the media streams terminated after the 200 OK CANCEL/BYE 

was sent? 
Repeat this test in reverse direction. 
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Test case number 


SS unsucc 010 


Test case group 


BCALL/unsuccessful 


Reference 


[31, [41 and [51 


SELECTION EXPRESSION 




Test purpose 


Codec not supported by the called user. 

The initial INVITE contains a SDP with codes that does not support by the called 

user. 

Ensure that, when the called user does not accept the Media session, the called 

user initiate call clearing to the calling user with 488 Not Acceptable Here, which 

also receives an ACK. 


Configuration 




SIP Parameter 


INVITE: codec not supported at user (Network B) 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

^ INVITE ^ 
^ 488 Not Acceptable Here ^ 
^ ACK ^ 


Comments 


Establish a call setup from network A to Network B. 

User B in Network B does not support the codec offered in the SDP received 

from Network A. 

Check: Is a 488 Not Acceptable Here sent from Network B to Network A. 

Repeat this test in reverse direction. 



Test case number 


SS unsucc 011 


Test case group 


BCALL/unsuccessful 


Reference 


[41 


SELECTION EXPRESSION 




Test purpose 


Call clearing due to no answer from the called user initiated by the 
originating network. 

Ensure that when there is no answer from the called user, the originating 
network initiate the call clearing after timeout of SIP timer C and sends a 
CANCEL or BYE to the called user. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

^ INVITE ^ 
^ 180 Ringing 
Start timer C 

Timeout timer C 

CANCEL/BYE ^ 
^ 200 OK CANCEL/BYE 
4- 487 Request Terminated 

ACK ^ 


Comments 


Check: Is a CANCEL or BYE request is sent by the originating network? 
Check: Is a 487 Request Terminating send from the terminating user? 
Check: Are the media streams terminated after the 200 OK CANCEL/BYE 

was sent? 
Repeat this test in reverse direction. 
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Test case number 


SS unsucc 012 


Test case group 


BCALL/unsuccessful 


Reference 


6.11.2/[241 


SELECTION EXPRESSION 


[Network B]SE 17 


Test purpose 


SIP-I support. Called number is not allocated in the PSTN/PLMN network. 

Ensure that, when calling to an unallocated number in the PSTN/PLMN part of 
network B and ISUP - SIP-I interworking applies in Network B, the network 
initiate call clearing to the calling user with a 404 Not Found message. A ISUP 
REL message is encapsulated and the Cause value indicator is set to '1'. 


Configuration 


The called user number is not assigned to the PSTN/PLMN part in Network B 


SIP Parameter 


404: 

Reason: Q.850;cause=1 (optional) 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

REL 

Cause value: 1 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 404 Not Found(REL) 

ACK ^ 


Comments 


Establish a communication from network A to Network B, called user number is 

not allocated in the PSTN/PLMN part of Network B 

Check: Is a 404 Not Found sent from Network B to Network A? 

Check: is a ISUP REL encapsulated and the Cause value indicator is set to 

'1'? 
Check: If a Reason header is present, is the cause value equal to the value in 

the Cause value of the encapsulated ISUP REL? 
Repeat this test in reverse direction. 
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Test case number 


SS unsucc 013 


Test case group 


BCALL/unsuccessful 


Reference 


6.11.2/[241 


SELECTION EXPRESSION 


[Network B]SE 17 AND SE 47 


Test purpose 


SIP-I support. The called user is busy. 

Ensure that, when the called user in the PSTN/PLMN part of Network B and 
ISUP - SIP-I interworking applies in Network B is busy, the network initiates call 
clearing to the calling user with a 486 Busy Here message. A ISUP REL 
message is encapsulated and the Cause value indicator is set to '17'. 


Configuration 


The called user is busy in the PSTN/PLMN part in Network B 


SIP Parameter 


486: 

Reason: Q.850;cause=17 (optional) 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

REL 

Cause value: 17 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 486 Busy Here(REL) 

ACK ^ 


Comments 


Establish a communication from network A to Network B, user B in the 

PSTN/PLMN part of Network B is busy. 

Check: Is a 486 Busy Here sent from Network B to Network A? 

Check: Is a ISUP REL encapsulated and the Cause value indicator is set to 

'17'? 
Check: If a Reason header is present, is the cause value equal to the value in 

the Cause value of the encapsulated ISUP REL? 
Repeat this test in reverse direction. 
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Test case number 


SS unsucc 014 


Test case group 


BCALL/unsuccessful 


Reference 


6.11.2/[241 


SELECTION EXPRESSION 


[Network B]SE 17 AND SE 47 


Test purpose 


SIP-I support. The called user rejects the call. 

Ensure that, when the called user in the PSTN/PLMN part of Network B and 
ISUP - SIP-I interworking applies in Network B rejects the communication setup, 
the network initiates call clearing to the calling user with a 480 Temporarily 
Unavailable final response. A ISUP REL message is encapsulated and the 
Cause value indicator is set to '21 '. 


Configuration 




SIP Parameter 


480: 

Reason: Q.850;cause=21 (optional) 

Content-Type: multipart/mixed;boundary=[any boundary name] 

--[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

REL 

Cause value: 21 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 480 Temporarily Unavailable (REL) 

ACK ^ 


Comments 


Establish a communication from network A to Network B, user B in the 
PSTN/PLMN part of network B rejects the communication setup. 
Check: Is a 480 Temporarily Unavailable sent from Network B to Network A? 
Check: is a ISUP REL encapsulated and the Cause value indicator is set to 

'21'? 
Check: If a Reason header is present, is the cause value equal to the value in 

the Cause value of the encapsulated ISUP REL? 
Repeat this test in reverse direction. 
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Test case number 


SS unsucc 015 


Test case group 


BCALL/unsuccessful 


Reference 


7.7.1/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 


Test purpose 


SIP-I support. Call clearing due to no answer from the called user initiated 
by the calling user. 

Ensure when the early dialogue is not confirmed by the called user, the calling 
user located in the PSTN/PLMN part of Network A and ISUP - SIP-I interworking 
applies in Network A initiates call clearing to the called user with CANCEL or 
BYE. An ISUP REL message is encapsulated in the BYE request and the Cause 
value indicator is set to '16'. 


Configuration 




SIP Parameter 


480: 

Reason: Q.850;cause=16 (optional) 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

REL 

Cause value: 16 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 180 Ringing 
CASE A 

CANCEL ^ 
^ 200 OK CANCEL 
4- 487 Request Terminated 

ACK ^ 

CASEB 

BYE(REL) ^ 
^ 200 OK BYE(RLC) 
4- 487 Request Terminated 

ACK ^ 


Comments 


Establish a communication from network A to Network B, user B does not 

confirm the communication. 

The originating user in the PSTN/PLMN part of Network A terminates the early 

dialogue. 

Check: Is a CANCEL or BYE request is sent from the originating network? 

Check: Is a ISUP REL encapsulated in a BYE request? 

Check: Is the Cause value of the encapsulated REL set to '1 6'? 

Check: If a Reason header is present, is the cause value equal to the value in 

the Cause value of the encapsulated ISUP REL? 
Check: Is a 487 Request Terminating send from the terminating user? 
Check: Are the media streams terminated after the 200 OK CANCEL/BYE 

was sent? 
NOTE: A ISUP REL is not encapsulated in a CANCEL request. 
Repeat this test in reverse direction. 
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Test case number 


SS unsucc 016 


Test case group 


BCALL/unsuccessful 


Reference 


7.7.1/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 


Test purpose 


SIP-I support. Call clearing due to no answer from the called user initiated 
by the originating network. 

Ensure when the early dialogue is not confirmed by the called user, the 
originating network initiate the call clearing after timeout of ISUP timer T9 if the 
calling user is located in the PSTN/PLMN part of Network A and ISUP - SIP-I 
interworking applies in Network A and the originating network sends a CANCEL 
or BYE to the called user. An ISUP REL message is encapsulated in the BYE 
request and the Cause value indicator is set to '19'. 


Configuration 




SIP Parameter 


480: 

Reason: Q.850;cause=19 (optional) 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

REL 

Cause value: 19 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

^ INVITE ^ 
^ 180 Ringing 
Start timer T9 

Timeout T9 
CASE A 

CANCEL ^ 
^ 200 OK CANCEL 
4- 487 Request Terminated 

ACK ^ 

CASEB 

BYE(REL) ^ 
^ 200 OK BYE(RLC) 
4- 487 Request Terminated 

ACK ^ 


Comments 


Establish a communication from network A to Network B, user B does not 

answer the communication setup. 

The ISUP timer T9 in the PSTN/PLMN expires 

Check: Is a CANCEL or BYE request is sent by the originating network? 

Check: Is a ISUP REL encapsulated in a BYE request? 

Check: Is the Cause value of the encapsulated REL set to '1 9'? 

Check: If a Reason header is present, is the cause value equal to the value in 

the Cause value of the encapsulated ISUP REL? 
Check: Is a 487 Request Terminating send from the terminating user? 
Check: Are the media streams terminated after the 200 OK CANCEL/BYE 

was sent? 
NOTE: A ISUP REL is not encapsulated in a CANCEL request. 
Repeat this test in reverse direction. 
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7.1 .5 Test purposes for Supplementary services 



7.1.5.1 



Test purposes for OIP 



Test case number 


88 oip 001 


Test case group 


8IP-8IP/8ervice/OIP 


Reference 


5.2.6.3/[2] 


SELECTION EXPRESSION 




Test purpose 


No P-Preferred-ldentity received. The terminating user receives the default 
public user identity of the originating user. 

In case the preconditions are fulfilled to provide the terminating UE with 
originating identification information without preventing the presentation, ensure 
that no identity information in the P-Preferred-ldentity header is provided by the 
originating UE, the terminating user receives a P-Asserted-ldentity based onj 
the default public user identity associated with the oriqinatina UE identifies the 
originator of the session. 


Configuration 




SIP Parameter 


INVITE 

P-Asserted-ldentity= default public user identity 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 


Comments 


Check: Is the P-Asserted-ldentity set to the default public user identity? 
Check: Is optional a second P-Asserted-ldentity header present as a 'tel' URI 

with a public user identity? 
Check: Is the user parameter is set to phone? 
Repeat this test in reverse direction. 
Repeat this test with all relevant end devices. 



Test case number 


88 oip 002 


Test case group 


8IP-8IP/8ervice/OIP 


Reference 


5.2.6.3/[2] 


SELECTION EXPRESSION 




Test purpose 


P-Preferred-ldentity received, no match with the set of registered public 
identities. The terminating user receives the default public user identity of 
the originating user. 

In case the preconditions are fulfilled to provide the terminating UE with 
originating identification information without preventing the presentation, ensure 
that an identity information in the P-Preferred-ldentity header is provided by the 
originating UE, does not match with the set of registered public identities of the _ 
originating UE the terminating user receives a P-Asserted-ldentity based on the 

originator of the session. 


Configuration 




SIP Parameter 


INVITE 

P-Asserted-ldentity= default public user identity 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 


Comments 


Check: Is the P-Asserted-ldentity set to the default public user identity? 
Check: Is optional a second P-Asserted-ldentity header present as a 'tel' URI 

with a public user identity? 
Check: Is the user parameter is set to phone? 
Check: Is the P-Preferred-ldentity header not present? 
Repeat this test in reverse direction. 
Repeat this test with all relevantend devices. 
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Test case number 


SS oip 003 


Test case group 


SIP-SIP/Service/OIP 


Reference 


5.2.6.3/f2] 


SELECTION EXPRESSION 




Test purpose 


P-Preferred-ldentity received, match with the set of registered public 
identities. The terminating user receives the registered public user identity 
of the originating user. 

In case the preconditions are fulfilled to provide the terminating UE with 
originating identification information without preventing the presentation, ensure 
that an identity information in the P-Preferred-ldentity header is provided by the 
originating UE, matches with the set of registered public identities of the 
originating UE the terminating user receives a P-Asserted-ldentity based on the 
information provided by the originating UE identifies the originator of the session. 


Configuration 




SIP Parameter 


INVITE 

P-Asserted-ldentity= matched public user identity' 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 


Comments 


Check: Is the P-Asserted-ldentity set to the identified public user identity? 
Check: Is optional a second P-Asserted-ldentity header present as a 'tel' URI 

with a public user identity? 
Check: Is the user parameter is set to phone? 
Check: Is the P-Preferred-ldentity header not present? 
Repeat this test in reverse direction. 
Repeat this test with all relevantend devices. 



Test case number 


SS oip 004 


Test case group 


SIP-SIP/Service/OIP 


Reference 


4.5.2.4/[7] 


SELECTION EXPRESSION 


SE 18 AND NOISE 19 


Test purpose 


No Special arrangement exists. 

The special arrangement does not exist (screening of user provided information). 
The network compares the information in the From header with the set of 
registered public identities of the originating user If is no match is found, the AS 
sets the From header to the SIP URI that includes the registered default public 
user identity. 


Configuration 


Special arrangement for the originating user does not exist 


SIP Parameter 


INVITE 

From=default public user identity 
P-Asserted-Header=[any registered public user identity] 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 


Comments 


Check: Is the From header URI set to the value of the P-Asserted-ldentity 

URI? 
Check: Is the P-Asserted-ldentity set to any registered public user identity? 
Check: Is the user parameter is set to phone? 
Repeat this test in reverse direction. 
Repeat this test with all relevantend devices. 
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Test case number 


SS oip 005 


Test case group 


SIP-SIP/Service/OIP 


Reference 


4.5.2.4/[7] 


SELECTION EXPRESSION 


SE18ANDSE 19 


Test purpose 


Special arrangement exists. 

The special arrangement exists (no screening of user provided information). The 
network does not attempt to match the information in the From header with the 
set of registered public identities of the originating user. The From header field is 
transparently transported to the terminating user. 


Configuration 


Special arrangement for the originating user exists 


SIP Parameter 


INVITE 

From= original value 

P-Asserted-Header=[any registered public user identity] 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 


Comments 


Check: Is the From header URI set to original value sent by the user? 
Check: Is the P-Asserted-ldentity set to any registered public user identity? 
Check: Is the user parameter is set to phone? 
Repeat this test in reverse direction. 
Repeat this test with all relevantend devices. 



ETSI 



61 



ETSI TS 101 585 VI .1.2 (2012-09) 



Test case number 


SS oip 006 


Test case group 


SIP-SIP/Service/OIP 


Reference 


7.1.3/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 52 


Test purpose 


SIP-I support. ISUP Calling party number presentation allowed in the 
encapsulated lAM. 

Ensure when BICC/ISUP - SIP-I interworking applies in the originating network 
the BICC/ISUP lAIVI is encapsulated in the INVITE request. The P-Asserted- 
Identity header field is derived from the Calling party number in the encapsulated 
lAM. The 'Presentation restriction' indicator in the encapsulated lAM is set to 
'allowed' no Privacy value 'id' is present in the INVITE request. 


Configuration 




SIP Parameter 


INVITE 

P-Asserted-ldentity=[derived from the ISUP calling party number] 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

lAM 

Calling party number 

Screening indicator 

Network provided or user provided, verified and 

passed 
Presentation restriction 

allowed 
Address signal 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(IAM) ^ 


Comments 


Check: Is a BICC/ISUP lAM encapsulated in the in the INVITE request? 
Check: Is the Calling party number present in the encapsulated lAM and the 

screening indicator is set to 'Network provided' or 'user provided, 

verified and passed' and the Presentation restriction indicator is set to 

'allowed'? 
Check: Is the P-Asserted-ldentity header field derived from the Calling party 

number in the encapsulated lAM? 
Check: Is the value 'id' not present in the Privacy header field (if included)? 
Repeat this test in reverse direction. 
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Test case number 


SS oip 007 


Test case group 


SIP-SIP/Service/OIP 


Reference 


7.1.3/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 52 


Test purpose 


SIP-I support. ISUP Additional Calling party number presentation allowed 
in the encapsulated lAM. 

Ensure when BICC/ISUP - SIP-I interworking applies in the originating network 
the BICC/ISUP lAIVI is encapsulated in the INVITE request. The From field is 
derived from the Additional Calling party number in the encapsulated lAM. The 
'Presentation restriction' indicator in the encapsulated lAM is set to 'allowed' no 
Privacy value 'id' is present in the INVITE request. 


Configuration 


The originating user in the PSTN/PLMN part of Network A is subscribed to the 
'no screening option' 


SIP Parameter 


INVITE 

From=[derived from the ISUP Additional calling party number] 
P-Asserted-ldentity=[derived from the ISUP calling party number] 

Content-Type: multipart/mixed;boundary=[any boundary name] 

--[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

lAM 

Calling party number 
Screening indicator 

Network Provided 
Presentation restriction 

allowed 
Address signal 
Generic number 

Number Qualifier Indicator 

Additional calling party number 
Screening indicator 

user provided, not verified 
Presentation restriction 

allowed 
Address signal 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(IAM) ^ 


Comments 


Check: Is a BICC/ISUP lAM encapsulated in the in the INVITE request? 
Check: Is the Calling party number present in the encapsulated lAM and the 

screening indicator is set to 'Network Provided' and the Presentation 

restriction indicator is set to 'allowed'? 
Check: Is the P-Asserted-ldentity header field derived from the Calling party 

number in the encapsulated lAM? 
Check: Is a Generic number parameter, Number Qualifier Indicator set to 

Additional calling party number present and the screening indicator 

is set to 'user provided, not verified' and the Presentation restriction 

indicator is set to 'allowed'? 
Check: Is the From header field derived from the Additional calling party 

number in the encapsulated lAM? 
Check: Is the value 'id' not present in the Privacy header field (if included)? 
Repeat this test in reverse direction. 
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7.1.5.2 



Test purposes for OIR 



Test case number 


88 oir 001 


Test case group 


8IP-8IP/8ervice/OIR 


Reference 


4.3.2, 4.5.2.4/ [7] 


SELECTION EXPRESSION 


8E20 


Test purpose 


Terminating user does not receive the identity of the originating user. 

In case the preconditions are fulfilled not to provide the terminating UE with 
originating identification information (e.g. permanent mode ), ensure that the P- 
Asserted-ldentity still contains identity information and the privacy is set to 'id' or 
'header' or 'user'. The terminating user does not receive the identity of the 
originating user. 
As a network option, the From header is set to an anonymous User Identity. 


Configuration 


Originating user subscribes to the OIR service 


SIP Parameter 


INVITE 

P-Asserted-ldentity: 
Privacy:id OR header OR user 

From: <sip:anonymous@anonymous.invalid> (optional) 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 


Comments 


Check: Is the P-Asserted-ldentity is present? 

Check: Is the Privacy header set to 'id' or 'header' or 'user'? 

Check: Is optional the From header set to an anonymous User Identity? 

Repeat this test in reverse direction. 

Repeat this test with all chosen end devices. 



Test case number 


88 oir 002 


Test case group 


8IP-8IP/8ervice/OIR 


Reference 


4.3.2, 4.5.2.4/[7] 


SELECTION EXPRESSION 


8E 20 AND 8E 25 


Test purpose 


Communication forwarding unconditional, served user subscribes OIR. 

The user A and user C are in network B and user C is provided with OIP. The 
user B is in network A and is provided with CFU "diverting number is released to 
the diverted-to user"=Yes. 

In case the served user subscribes Originating Identification Restriction (e.g. 
permanent mode), ensure that when user A calls user B, the call is forwarded 
unconditional to user C, user C is not informed of the forwarding number. The 
diverted-to user receives no identity of the diverting user neither in a History-Info 
header nor in the To header. 


Configuration 


Diverting user subscribes to the OIR service 


SIP Parameter 


INVITE: no history entry present 

INVITE: 

History-Info header: 

<sip:userB@networkA?Privacy=history >;index=1 , 
<sip: userC@networkB;cause=302 >;index=1.1 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

^ INVITE 
CFU is performed in Network A 
INVITE ^ 
Apply post test routine 


Comments 


Check: No History-Info header is received in the INVITE from Network B. 
Check: Is the Privacy value history is escaped in the hi-targed-to-uri of the 

diverting user in Network A? 
Repeat this test in reverse direction. 
Repeat this test with all chosen end devices. 
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Test case number 


SS oir 003 


Test case group 


SIP-SIP/Service/OIR 


Reference 


7.1.3/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 52 


Test purpose 


SIP-I support. ISUP Calling party number presentation restricted in the 
encapsulated lAM. 

Ensure when BICC/ISUP - SIP-I interworking applies in the originating network 
the BICC/ISUP lAM is encapsulated in the INVITE request. The 
P- Asserted- Identity header field is derived from the Calling party number in the 
encapsulated lAM. The 'Presentation restriction' indicator in the encapsulated 
lAM is set to 'restricted' the value 'id' is present in the Privacy header of the 
INVITE request. 


Configuration 




SIP Parameter 


INVITE 

P-Asserted-ldentity=[derived from the ISUP calling party number] 

Privacy: id 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

lAM 

Calling party number 
Screening indicator 

Network provided or user provided, verified and 

passed 
Presentation restriction 

restricted 
Address signal 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(IAM) ^ 


Comments 


Check: Is a BICC/ISUP lAM encapsulated in the in the INVITE request? 
Check: Is the Calling party number present in the encapsulated lAM and the 

screening indicator is set to 'Network provided' or 'user provided, 

verified and passed' and the Presentation restriction indicator is set to 

'restricted'? 
Check: Is the P-Asserted-ldentity header field derived from the Calling party 

number in the encapsulated lAM? 
Check: Is the value 'id' present in the Privacy header field? 
Repeat this test in reverse direction. 
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Test case number 


SS oir 004 


Test case group 


SIP-SIP/Service/OIR 


Reference 


7.1.3/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 52 


Test purpose 


SIP-I support. ISUP Additional Calling party number presentation restricted 
in the encapsulated lAM. 

Ensure when BICC/ISUP - SIP-I interworking applies in the originating network 
the BICC/ISUP lAIVI is encapsulated in the INVITE request. The From field is 
derived from the Additional Calling party number in the encapsulated lAM. The 
'Presentation restriction' indicator in the Generic number parameter is set to 
'allowed' no Privacy value 'id' is present in the INVITE request. 


Configuration 


The originating user in the PSTN/PLMN part of Network A is subscribed to the 
'no screening option' 


SIP Parameter 


INVITE 

P-Asserted-ldentity=[derived from the ISUP calling party number] 
From=[derived from the ISUP Additional calling party number] 

Privacy: id 

Content-Type: multipart/mixed;boundary=[any boundary name] 

--[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

lAM 

Calling party number 
Screening indicator 

Network Provided 
Presentation restriction 

restricted 
Address signal 
Generic number 

Number Qualifier Indicator 

Additional calling party number 
Screening indicator 

user provided, not verified 
Presentation restriction 

restricted 
Address signal 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(IAM) ^ 


Comments 


Check: Is a BICC/ISUP lAM encapsulated in the in the INVITE request? 
Check: Is the Calling party number present in the encapsulated lAM and the 

screening indicator is set to 'Network Provided' and the Presentation 

restriction indicator is set to 'restricted'? 
Check: Is the P-Asserted-ldentity header field derived from the Calling party 

number in the encapsulated lAM? 
Check: Is a Generic number parameter, Number Qualifier Indicator set to 

Additional calling party number present and the screening indicator 

is set to 'user provided, not verified' and the Presentation restriction 

indicator is set to 'restricted'? 
Check: Is the From header field derived from the Additional calling party 

number in the encapsulated lAM? 
Check: Is the value 'id' present in the Privacy header field? 
Repeat this test in reverse direction. 
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7.1.5.3 



Test purposes for TIP 



Test case number 


88 tip 001 


Test case group 


8IP-8IP/8ervice/TIP 


Reference 


5.2.6.4/[8] 


SELECTION EXPRESSION 




Test purpose 


Originating user receives the identity of the terminating user. 

Ensure in case tine preconditions are fulfilled to provide the originating UE with 
terminating identification information without preventing the presentation , the 
originating UE receives in a Ixx or 200 SIP response a P-Asserted-ldentity 
header field with a valid public user identity of the terminating UE. 


Configuration 




SIP Parameter 


18X/200 OK INVITE 

P-Asserted-ldentity: 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 

CASE A ^ 180 Ringing 

CASE B ^183 Session Progress 

CASE C ^ 200 OK INVITE(P-Asserted-ldentity) 

Apply post test routine 


Comments 


Check: Is the P-Asserted-ldentity is present in a 180 Ringing or 183 Session 

Progress or in a 200 OK INVITE? 
Repeat this test in reverse direction. 
Repeat this test with all relevant end devices. 
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Test case number 


SS tip 002 


Test case group 


SIP-SIP/Service/TIP 


Reference 


4.5.2.9/[8] 


SELECTION EXPRESSION 


SE 21 AND SE 22 AND [Network B] SE 48 


Test purpose 


Second identity provided in UPDATE. 

Ensure that, when the option tag "from-change" in the Supported header field 
is provided by the originating UE in the INVITE request and the terminating UE 
receives the from-change tag, The terminating user sends a 'from-change' tag in 
the supported header in the 200 OK INVITE a second identity is provided in the 
UPDATE request sent by the terminated user in the From header after the ACK 
was received. 


Configuration 


Special arrangement for the terminating user exists 


SIP Parameter 


INVITE 

Supported: from-change 

200 OK INVITE 

P-Asserted-ldentity: 

UPDATE 

From: (second user identity) 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 180 Ringing 
^ 200 OK INVITE(P-Asserted-ldentity) 

ACK ^ 
^ UPDATE (From) 

200 OK UPDATE ^ 
Apply post test routine 


Comments 


Check: Is the 'from-change' tag present in the Supported header of the initial 

INVITE request? 
Check: Is the P-Asserted-ldentity is present in a 180 Ringing or 183 Session 

Progress or in a 200 OK INVITE? 
Check: Is the 'from-change' tag present in the supported header of the 

provisional (18x) or final (200 OK) response? 
Check: Is an UPDATE request sent by the terminating user containing a From 

header field set to the value send by the terminating user? 
Repeat this test in reverse direction. 
Repeat this test with all chosen end devices. 
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Test case number 


SS tip 003 


Test case group 


SIP-SIP/Service/TIP 


Reference 


4.5.2.9/[8] 


SELECTION EXPRESSION 


SE 21 AND SE 22 AND [Network B] SE 48 


Test purpose 


Second identity not provided. 

Ensure that, when the option tag "from-change" in the Supported header field 
is provided by the originating UE in the INVITE request, the terminating user 
does not receive the from-change tag in the initial INVITE, no from-change tag is 
sent in the 200 OK INVITE response, an UPDATE containing a second identity is 
sent and the From header is set to the default public user identity of the 
terminating user. 


Configuration 


Special arrangement for the terminating user does not exist 


SIP Parameter 


INVITE 

Supported: from-change 

200 OK INVITE 

P-Asserted-ldentity: 

UPDATE 

From: (default public user identity) 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 180 Ringing 
^ 200 OK INVITE(P-Asserted-ldentity) 

ACK ^ 
^ UPDATE (From) 

200 OK UPDATE ^ 
Apply post test routine 


Comments 


Check: Is the 'from-change' tag present in the Supported header of the initial 

INVITE request? 
Check: Is the P-Asserted-ldentity is present in the 200 OK INVITE? 
Check: Is the 'from-change' tag present in the supported header of the 

provisional (18x) or final (200 OK) response? 
Check: Is an UPDATE request sent by the terminating user containing a From 

header field set to the public user identity of the terminating user? 
Repeat this test in reverse direction. 
Repeat this test with all relevant end devices. 
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Test case number 


SS tip 004 


Test case group 


SIP-SIP/Service/TIP 


Reference 


6.7/[241 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 53 


Test purpose 


SIP-I support. The Connected number presentation allowed is present in 
the encapsulated 200 OK. 

Ensure that on receipt of a 200 OK INVITE to establish a confirmed dialogue an 
ANM is encapsulated if SIP-I - BICC/ISUP interworking is applicable in Network 
B. The Address presentation restriction indicator is set to 'allowed'. The 
screening indicator is set to Network provided or user provided, verified and 
passed. 


Configuration 




SIP Parameter 


200 OK INVITE 

Content-Type: multipart/nnixed;boundary=[any boundary name] 

--[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

ANM 

Connected number 

Screening indicator 

Network provided or user provided, verified and 

passed 
Address presentation restriction 

allowed 
Address signal 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(IAM) ^ 
^ 180Ringing(ACM) 
^ 200 OK INVITE(ANM) 

ACK ^ 
Apply post test routine 


Comments 


Check: Is the BICC/ISUP ANM encapsulated in the 200 OK INVITE final 

response? 
Check: Is the Screening indicator in the encapsulated ANM set to 'Network 

provided' or 'user provided, verified and passed'? 
Check: Is the Address presentation restriction indicator in the encapsulated 

ANM set to allowed? 
Repeat this test in reverse direction. 
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Test case number 


SS tip 005 


Test case group 


SIP-SIP/Service/TIP 


Reference 


6.7/[241 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 53 


Test purpose 


SIP-I support. The additional connected number restricted is present in the 
encapsulated 200 OK. 

Ensure that on receipt of a 200 OK INVITE to establish a confirmed dialogue an 
ANM is encapsulated if SIP-I - BICC/ISUP interworking is applicable in Network 
B. A Generic number parameter is present the Number qualifier indicator set to 
'additional connected number' the Screening indicator is set to 'user provided, 
not verified' and the Address Presentation Restricted is set to 'allowed'. 
A Connected number parameter is present the Screening indicator is set to 
'Network provided' and the Address Presentation Restricted indicator is set to 
'allowed'. 


Configuration 


The terminating user in the PSTN/PLMN part of Network B is subscribed to the 
COLP 'no screening option' 


SIP Parameter 


200 OK INVITE 

P-Asserted-ldentity=[derived from the ISUP Connected number] 

Content-Type: multipart/mixed;boundary=[any boundary name] 

--[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

ANM 

Connected number 

Screening indicator 

Network provided or user provided, verified and 

passed 
Presentation restriction 

allowed 
Address signal 
Generic number 

Number Qualifier Indicator 

Additional calling party number 
Screening indicator 

user provided, not verified 
Address Presentation Restricted 

allowed 
Address signal 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(IAM) ^ 
^ 180Ringing(ACM) 
^ 200 OK INVITE(ANM) 

ACK ^ 
Apply post test routine 


Comments 


Check: Is the BICC/ISUP ANM encapsulated in the 200 OK INVITE final 

response? 
Check: Is a Generic number parameter present in the encapsulated ANM? 
Check: Is the Number Qualifier Indicator of the Generic number set to 

'additional connected number'? 
Check: Is the Screening indicator of the Generic number set to 'user provided, 

not verified'? 
Check: Is the Address presentation restriction indicator in the Generic number 

set to 'allowed'? 
Repeat this test in reverse direction. 
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7.1.5.4 



Test purposes for TIR 



Test case number 


88 tir 001 


Test case group 


8IP-8IP/8ervice/TIR 


Reference 


4.5.2.9/[8] 


SELECTION EXPRESSION 


8E23 


Test purpose 


Originating user does not receive the identity of the terminating user. 

Ensure that, when the preconditions are fulfilled to prevent the presentation of 

the terminating user identity at the originating user, 

the originating UE receives, in any non-100 SIP response (e.g. 180, 183, 200), a 

Privacy header field is set to "id" and no P-Asserted-ldentity header field is 

present. 


Configuration 


The terminating user subscribes to the TIR' service 


SIP Parameter 


18X/200 OK INVITE 

P-Asserted-ldentity: 
Privacy: id 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 

CASE A ^ 180 Ringing 

CASE B ^183 Session Progress 

CASE C ^ 200 OK INVITE(P-Asserted-ldentity) 

Apply post test routine 


Comments 


Check: Is the P-Asserted-ldentity is present in the provisional (18x) or final 

(200 OK) response? 
Check: Is the Privacy header in the provisional (1 8x) or final (200 OK) 

response is set to 'id'? 
Repeat this test in reverse direction. 
Repeat this test with all chosen end devices. 
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Test case number 


SS tir 002 


Test case group 


SIP-SIP/Service/TIR 


Reference 


6.7/[241 


SELECTION EXPRESSION 


[Network B] SE 17 AND SE 47 AND SE 53 


Test purpose 


SIP-I support. The Connected number presentation allowed is present in 
the encapsulated 200 OK. 

Ensure that on receipt of a 200 OK INVITE to establish a confirmed dialogue an 
ANM is encapsulated if SiP-i - BICC/iSUP interworking is applicable in Network 
B. The Address presentation restriction indicator is set to 'restricted'. The 
screening indicator is set to 'Network provided' or 'user provided, verified and 
passed'. 


Configuration 




SIP Parameter 


200 OK INVITE 

Content-Type: multipart/nnixed;boundary=[any boundary name] 

--[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

ANM 

Connected number 

Screening indicator 

Network provided or user provided, verified and 

passed 
Address presentation restriction 

restricted 
Address signal 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(IAM) ^ 
^ 180Ringing(ACM) 
^ 200 OK INVITE(ANM) 

ACK ^ 
Apply post test routine 


Comments 


Check: Is the BICC/ISUP ANM encapsulated in the 200 OK INVITE final 

response? 
Check: Is the Screening indicator in the encapsulated ANM set to 'Network 

provided' or 'user provided, verified and passed'? 
Check: Is the Address presentation restriction indicator in the encapsulated 

ANM set to allowed? 
Repeat this test in reverse direction. 
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Test case number 


SS tir 003 


Test case group 


SIP-SIP/Service/TIR 


Reference 


6.7/[241 


SELECTION EXPRESSION 


[Network B] SE 17 AND SE 47 AND SE 53 


Test purpose 


SIP-I support. The additional connected number restricted is present in the 
encapsulated 200 OK. 

Ensure that on receipt of a 200 OK INVITE to establish a confirmed dialogue an 
ANM is encapsulated if SIP-I - BICC/ISUP interworking is applicable in Network 
B. A Generic number parameter is present the Number qualifier indicator set to 
'additional connected number' the Screening indicator is set to 'user provided, 
not verified' and the Address Presentation Restricted is set to 'restricted'. 
A Connected number parameter is present the Screening indicator is set to 
'Network provided' and the Address Presentation Restricted indicator is set to 
'restricted'. 


Configuration 


The terminating user in the PSTN/PLMN part of Network B is subscribed to the 
COLP 'no screening option' 


SIP Parameter 


200 OK INVITE 

P-Asserted-ldentity=[derived from the ISUP Connected number] 

Content-Type: multipart/mixed;boundary=[any boundary name] 

--[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

ANM 

Connected number 

Screening indicator 

Network provided or user provided, verified and 

passed 
Presentation restriction 

restricted 
Address signal 
Generic number 

Number Qualifier Indicator 

Additional calling party number 
Screening indicator 

user provided, not verified 
Address Presentation Restricted 

restricted 
Address signal 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(IAM) ^ 
^ 180Ringing(ACM) 
^ 200 OK INVITE(ANM) 

ACK ^ 
Apply post test routine 


Comments 


Check: Is the BICC/ISUP ANM encapsulated in the 200 OK INVITE final 

response? 
Check: Is a Generic number parameter present in the encapsulated ANM? 
Check: Is the Number Qualifier Indicator of the Generic number set to 

'additional connected number'? 
Check: Is the Screening indicator of the Generic number set to 'user provided, 

not verified'? 
Check: Is the Address presentation restriction indicator in the Generic number 

set to 'allowed'? 
Repeat this test in reverse direction. 
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7.1.5.5 



Communication Hold (HOLD) 



Test case number 


SS hold 001 


Test case group 


SIP-SIP/Service/HOLD 


Reference 


4.5.2.1/[17] 


SELECTION EXPRESSION 


SE24 


Test purpose 


Hold the session the media stream was previously set to sendrecv. 

Ensure that the UE A requesting hold of the session sends an INVITE or 
UPDATE request to hold the session. Hold is done containing the SDP with the 
attribute "a=sendonly". The UE A after requesting the hold session receives 200 
OK final response containing the SDP with the attribute "a=recvonly". 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

A confirmed session already exists 
CASE A INVITE(sendonly) ^ 

^ 200 OK INVITE (recvonly) 

ACK ^ 

CASE B UPDATE(sendonly) ^ 

^ 200 OK UPDATE (recvonly) 
Apply post test routine 


Comments 


Check: Is the user in network A able to set the session on hold by sending an 
INVITE or UPDATE request and the version parameter in the SDP 'o' 
line is incremented? 

Repeat this test in reverse direction. 
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Test case number 


SS hold 002 


Test case group 


SIP-SIP/Service/HOLD 


Reference 


4.5.2.1/f17] 


SELECTION EXPRESSION 


SE24 


Test purpose 


Hold the session the media stream was previously set to recvonly. 

Ensure that the UE A requesting hold of the session stops sending media and 
sends an INVITE or UPDATE request to hold the session. Hold is done 
containing the SDP with the attribute "a=inactive". The UE A after requesting to 
resume the held session receives 200 OK final response containing the SDP 
with the attribute "a=inactive." 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

A confirmed session already exists 
CASE A ^ INVITE (sendonly) 

200 OK INVITE (recvonly) ^ 
^ ACK 

INVITE (inactive) ^ 
^ 200 OK INVITE (inactive) 

ACK ^ 

CASE B ^ INVITE (sendonly) 

200 OK INVITE (recvonly) ^ 
^ ACK 

UPDATE(inactive) ^ 
^ 200 OK UPDATE (inactive) 

CASE C ^ UPDATE (sendonly) 

200 OK UPDATE (recvonly) ^ 
INVITE (inactive) ^ 
^ 200 OK INVITE (inactive) 

ACK ^ 

CASE D ^ UPDATE (sendonly) 

200 OK UPDATE (recvonly) ^ 
UPDATE(inactive) ^ 
^ 200 OK UPDATE (inactive) 
Apply post test routine 


Comments 


Check: Is the user in network B able to set the session on hold by sending an 

INVITE or UPDATE request and the version parameter in the SDP 'o' 

line is incremented? 
Check: Is the user in network A able to set the session on hold by sending an 

INVITE or UPDATE request and the version parameter in the SDP 'o' 

line is incremented? 
Repeat this test in reverse direction. 
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Test case number 


SS hold 003 


Test case group 


SIP-SIP/Service/HOLD 


Reference 


4.5.2.1/f17] 


SELECTION EXPRESSION 


SE24 


Test purpose 


Resume the session the media stream was previously set to sendonly. 

Ensure that the UE A is requested to resume the session with user B the UE-A 
starts sending media and sends an INVITE or UPDATE request to resume the 
session with the attribute "a=sendrecv in the SDP. The UE A after requesting to 
resume the held session receives 200 OK final response and optionally the 
attribute "a=sendrecv in the SDP. The a=sendrecv attribute is the default value 
therefore the attribute can be omitted. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

A confirmed session already exists 
CASE A INVITE (sendonly) ^ 

^ 200 OK INVITE (recvonly) 

ACK ^ 
INVITE (sendrecv) ^ 

^ 200 OK INVITE (sendrecv) 

ACK ^ 

CASE B INVITE (sendonly) ^ 

^ 200 OK INVITE (recvonly) 

ACK ^ 
UPDATE (sendrecv) ^ 
^ 200 OK UPDATE (sendrecv) 

CASE C UPDATE (sendonly) ^ 

^ 200 OK UPDATE (recvonly) 

INVITE (sendrecv) ^ 
^ 200 OK INVITE (sendrecv) 

ACK ^ 

CASE D UPDATE (sendonly) ^ 

^ 200 OK UPDATE (recvonly) 

UPDATE (sendrecv) ^ 
^ 200 OK UPDATE (sendrecv) 
Apply post test routine 


Comments 


Check: Is the user in network A able to set the session on hold by sending an 
INVITE or UPDATE request and the version parameter in the SDP 'o' 
line is incremented? 

Check: Is the user in network A able to retrieve the session by sending an 

INVITE or UPDATE request and the version parameter in the SDP 'o' 
line is incremented? The absence of the 'sendrecv' attribute is the 
default value. 

Repeat this test in reverse direction. 
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Test case number 


SS hold 004 


Test case group 


SIP-SIP/Service/HOLD 


Reference 


4.5.2.1/f17] 


SELECTION EXPRESSION 


SE24 


Test purpose 


Resume the session the media stream was previously set to inactive. 




The Session is in the "inactive" state. Ensure that the UE A is requesting to 




resume the session with user B the UE-A sends an INVITE or UPDATE to 




resume the session with the attribute "a=recvonly in the SDP. The UE A after 




requesting to resume the held session receives 200 OK final response and 




optionally the attribute ^'a=sendonly in the SDP. 


Configuration 




SIP Parameter 




Message flow 




SIP (Network A) 


Interconnection Interface SIP (Network B) 




A confirmed session already exists 


CASE A 


^ INVITE(sendonly) 




200 OK INVITE (recvonly) ^ 




^ ACK 




INVITE(inactive) ^ 




^ 200 OK INVITE (inactive) 




ACK ^ 




INVITE (recvonly) ^ 




^ 200 OK INVITE (sendorJ) 




ACK ^ 


CASEB 


^ INVITE(sendonly) 




200 OK INVITE (recvonly) ^ 




^ ACK 




UPDATE(inactive) ^ 




^ 200 OK UPDATE (inactive) 




INVITE (recvonly) ^ 




^ 200 OK INVITE (^IH) 




ACK ^ 


CASEC 


^ UPDATE (sendonly) 




200 OK UPDATE (recvonly) ^ 




INVITE(inactive) ^ 




^ 200 OK INVITE (inactive) 




ACK ^ 




UPDATE (recvonly) ^ 




^ 200 OK UPDATE (^IH) 


CASED 


^ UPDATE (sendonly) 




200 OK UPDATE (recvonly) ^ 




UPDATE(inactive) ^ 




^ 200 OK UPDATE (inactive) 




UPDATE (recvonly) ^ 




^ 200 OK UPDATE (sfiadi*) 




Apply post test routine 


Comments 


Check: Is the user in network B able to set the session on hold by sending an 




INVITE or UPDATE request and the version parameter in the SDP 'o' 




line is incremented? 




Check: Is the user in network A able to set the session on hold by sending an 




INVITE or UPDATE request and the version parameter in the SDP 'o' 




line is incremented? 




Check: Is the user in network A able to retrieve the session by sending an 




INVITE or UPDATE request and the version parameter in the SDP 'o' 




line is incremented? 




Repeat this test in reverse direction. 
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Test case number 


SS hold 005 


Test case group 


SIP-SIP/Service/HOLD 


Reference 


4.5.2.1/f17] 


SELECTION EXPRESSION 


SE24 


Test purpose 


Hold the session the media stream was previously set to sendrecv. 

Ensure that the UE A receives an INVITE or UPDATE request to hold the 
session and stops sending media. Hold is done containing the SDP with the 
attribute "a=sendonly". The UE A after resuming the held session sends a 200 
OK final response containing the SDP with the attribute "a=recvonly". 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

A confirmed session already exists 
CASE A ^ INVITE(sendonly) 

200 OK INVITE(recvonly) ^ 
^ ACK 

CASE B ^ UPDATE(sendonly) 

200 OK UPDATE (recvonly) ^ 
Apply post test routine 


Comments 


Check: Is the user in network B able to set the session on hold by sending an 
INVITE or UPDATE request and the version parameter in the SDP 'o' 
line is incremented? 

Repeat this test in reverse direction. 
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Test case number 


SS hold 006 


Test case group 


SIP-SIP/Service/HOLD 


Reference 


4.5.2.1/f17] 


SELECTION EXPRESSION 


SE24 


Test purpose 


Hold the session the media stream was previously set to sendonly. 

The Session is in the "sendonly" state. Ensure that the UE A receives an INVITE 
or UPDATE request to hold the session and stops sending media. Hold is done 
containing the SDP with the attribute "a=inactive". The UE A after receiving the 
hold session sends 200 OK final response containing the SDP with the attribute 
"a=inactive". 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

A confirmed session already exists 
CASE A INVITE(sendonly) ^ 

^ 200 OK INVITE (recvonly) 

ACK ^ 
^ INVITE (inactive) 

200 OK INVITE (inactive) ^ 
^ ACK 

CASE B INVITE(sendonly) ^ 

^ 200 OK INVITE (recvonly) 

ACK ^ 
^ UPDATE (inactive) 

200 OK UPDATE (inactive) ^ 

CASE C UPDATE (sendonly) ^ 

^ 200 OK UPDATE (recvonly) 
^ INVITE (inactive) 

200 OK INVITE (inactive) ^ 
^ ACK 

CASE D UPDATE (sendonly) ^ 

^ 200 OK UPDATE (recvonly) 
^ UPDATE (inactive) 

200 OK UPDATE (inactive) ^ 

Apply post test routine 


Comments 


Check: Is the user in network A able to set the session on hold by sending an 

INVITE or UPDATE request? 
Check: Is the user in network B able to set the session on hold by sending an 

INVITE or UPDATE request and the version parameter in the SDP 'o' 

line is incremented? 
Repeat this test in reverse direction. 
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Test case number 


SS hold 007 


Test case group 


SIP-SIP/Service/HOLD 


Reference 


4.5.2.1/f17] 


SELECTION EXPRESSION 


SE24 


Test purpose 


Resume the session the media stream was previously set to recvonly. 

Ensure that the UE A receives an INVITE or UPDATE request requesting to 
resume the session with user B, the UE-A starts sending media. Resume is done 
containing the SDP with the attribute "a=sendrecv". The UE A after receiving the 
Resume of the session sends 200 OK final response containing the SDP with 
the attribute "a=sendrecv". The a=sendrecv attribute is the default value 
therefore the attribute can be omitted. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

A confirmed session already exists 
CASE A ^ INVITE (sendonly) 

200 OK INVITE(recvonly) ^ 
^ ACK 
^ INVITE(sendrecv) 

200 OK INVITE(sendrecv) ^ 
^ ACK 

CASE B ^ UPDATE (sendonly) 

200 OK UPDATE (recvonly) ^ 
^ UPDATE (sendrecv) 

200 OK UPDATE (sendrecv) ^ 
Apply post test routine 


Comments 


Check: Is the user in network B able to set the session on hold by sending an 

INVITE or UPDATE request and the version parameter in the SDP 'o' 

line is incremented? 
Check: Is the user in network B able to retrieve the session by sending an 

INVITE or UPDATE request and the version parameter in the SDP 'o' 

line is incremented? 
Repeat this test in reverse direction. 
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Test case number 



SS hold 008 



Test case group 



SIP-SIP/Service/HOLD 



Reference 



4.5.2.1/[17] 



SELECTION EXPRESSION 



SE24 



Test purpose 



Resume the session the media stream was previously set to inactive. 

The Session is in the "inactive" state. Ensure that the UE A receives an INVITE 
or UPDATE request requesting to resume the session with user B, the UE-A 
starts sending media. Resume is done containing the SDP with the attribute 
"a=recvonly". The UE A after receiving the Resume of t he sessio n sends 200 OK 
final response containing the SDP with the attribute "a=^endoniy". The 
a=sendrecv attribute is the default value therefore the attribute can be omitted. 



Configuration 



SIP Parameter 



Message flow 

SIP (Network A) 

CASE A 



CASEB 



CASEC 



CASED 



Interconnection Interface 
A confirmed session already exists 

INVITE (sendonly) ^ 

^ 200 OK INVITE (recvonly) 

ACK ^ 

^ INVITE (inactive) 

200 OK INVITE (inactive) ^ 

^ ACK 

^ INVITE (rec vonly) 

200 OK INVITE i 
^ ACK 



INVITE (sendonly) ^ 

^ 200 OK INVITE (recvonly) 

ACK ^ 

^ UPDATE (inactive) 

200 OK UPDATE (inactive) ^ 

^ UPDATE (recvonly) 

200 OK UPDATE (^IH) ^ 



UPDATE (sendonly) 
^ 200 OK UPDATE (recvonly) 

^ INVITE (inactive) 

200 OK INVITE (inactive) 
^ ACK 

^ INVITE (recvonly) 

200 OK INVITE (sendonf) 
^ ACK 



UPDATE (sendonly) ^ 

^ 200 OK UPDATE (recvonly) 

^ UPDATE (inactive) 

200 OK UPDATE (inactive) ^ 

^ UPDATE (recvonly) 

200 OK UPDATE (^IH) ^ 
Apply post test routine 



SIP (Network B) 



Comments 



Check: Is the user in network B able to set the session on hold by sending an 

INVITE or UPDATE request and the version parameter in the SDP 'o' 

line is incremented? 
Check: Is the user in network A able to set the session on hold by sending an 

INVITE or UPDATE request and the version parameter in the SDP 'o' 

line is incremented? 
Check: Is the user in network B able to retrieve the session by sending an 

INVITE or UPDATE request and the version parameter in the SDP 'o' 

line is incremented? 
Repeat this test in reverse direction. 
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Test case number 



SS hold 009 



Test case group 



SIP-SIP/Service/HOLD 



Reference 



4.5.2.1/[17] 



SELECTION EXPRESSION 



SE24 



Test purpose 



Resume the session on both sides the media stream was previously set to 
inactive. 

The Session is in the "inactive" state. Ensure that the UE A is requesting to 
resume the session with user B, the UE-A starts sending media and sends an 
INVITE or UPDATE request to resume the session with the attribute 
"a=sendonly in the SDP. The UE A after requests to resume the session 
receives 200 OK final response containing the SDP with the attribute 
"a=recvonly. The UE B after requests to resume the session receives 200 OK 
final response containing the SDP with the attribute "a=sendrecv". The 
a=sendrecv attribute is the default value therefore the attribute can be omitted. 



Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

A confirmed session already exists 
CASE A INVITE(sendonly) ^ 

^ 200 OK INVITE (recvonly) 

ACK ^ 

^ INVITE(inactive) 

200 OK INVITE (inactive) ^ 

^ ACK 

INVITE(sendonly) ^ 

^ 200 OK INVITE (recvonly) 

ACK ^ 

^ INVITE(sendrecv) 

200 OK INVITE (sendrecv) ^ 

^ ACK 

CASE B INVITE(sendonly) ^ 

^ 200 OK INVITE (recvonly) 

ACK ^ 

^ UPDATE (inactive) 

200 OK UPDATE (inactive) ^ 

INVITE(sendonly) ^ 

^ 200 OK INVITE (recvonly) 

ACK ^ 

^ UPDATE (sendrecv) 

200 OK UPDATE (sendrecv) ^ 

CASE C UPDATE (sendonly) ^ 

^ 200 OK UPDATE (recvonly) 

^ INVITE(inactive) 

200 OK INVITE (inactive) ^ 

^ ACK 

UPDATE (sendonly) ^ 

^ 200 OK UPDATE (recvonly) 

ACK ^ 

^ INVITE(sendrecv) 

200 OK INVITE (sendrecv) ^ 

^ ACK 

CASE D UPDATE (sendonly) ^ 

^ 200 OK UPDATE (recvonly) 

^ UPDATE (inactive) 

200 OK UPDATE (inactive) ^ 

UPDATE (sendonly) ^ 

^ 200 OK UPDATE (recvonly) 

^ UPDATE (sendrecv) 

200 OK UPDATE (sendrecv) ^ 
Apply post test routine 
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Comments 


Check: Is the user in network A able to set the session on hold by sending an 

INVITE or UPDATE request and the version parameter in the SDP 'o' 

line is incremented? 
Check: Is the user in network B able to set the session on hold by sending an 

INVITE or UPDATE request and the version parameter in the SDP 'o' 

line is incremented? 
Check: Is the user in network A able to retrieve the session by sending an 

INVITE or UPDATE request and the version parameter in the SDP 'o' 

line is incremented? 
Check: Is the user in network B able to retrieve the session by sending an 

INVITE or UPDATE request and the version parameter in the SDP 'o' 

line is incremented? The absence of the 'sendrecv' attribute is the 

default value. 
Repeat this test in reverse direction. 
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Test case number 


SS hold 


010 




Test case group 


SIP-SIP/Service/HOLD 


Reference 


4.5.2.1/f17] 


SELECTION EXPRESSION 


SE24 


Test purpose 


Resume the session on both sides the media stream was previously set to 




inactive. 








The Session is in the "inactive" state. Ensure that the UE A receives an INVITE 




or UPDATE to resume the session with user 


B, the UE-A starts sending media. 




Resume 


is done containing the SDP with the attribute "a=recvonly". The UE A 




after receiving the Resume of the session sends 200 OK final response 




containing the SDP with the attribute "a=sendonly". The UE A after requests to 




resume the session receives 200 OK final response containing the SDP with the 




attribute 


'a=sendrecv. The UE B after receiving the Resume of the session 




sends 200 OK final response containing the SDP with the attribute "a=sendrecv". 




The a=sendrecv attribute is the default value therefore the attribute can be 




omitted. 






Configuration 




SIP Parameter 




Message flow 








SIP (Network A) 




Interconnection Interface 


SIP (Network B) 




A confirmed session already exists 




CASE A 


^ 


INVITE(sendonly) 








200 OK INVITE (recvonly) 


^ 




^ 


ACK 








INVITE(inactive) 


^ 




^ 


200 OK INVITE (inactive) 








ACK 


^ 




^ 


INVITE(sendonly) 








200 OK INVITE (recvonly) 


^ 




^ 


ACK 








INVITE(sendrecv) 


^ 




^ 


200 OK INVITE (sendrecv) 








ACK 


^ 


CASEB 


^ 


INVITE(sendonly) 








200 OK INVITE (recvonly) 


^ 




^ 


ACK 








UPDATE (inactive) 


^ 




^ 


200 OK UPDATE (inactive) 






^ 


INVITE(sendonly) 








200 OK INVITE (recvonly) 


^ 




^ 


ACK 








UPDATE (sendrecv) 


^ 




^ 


200 OK UPDATE (sendrecv) 




CASEC 


^ 


UPDATE (sendonly) 








200 OK UPDATE (recvonly) 


^ 






INVITE(inactive) 


^ 




^ 


200 OK INVITE (inactive) 








ACK 


^ 




^ 


UPDATE (sendonly) 








200 OK UPDATE (recvonly) 


^ 






INVITE(sendrecv) 


^ 




^ 


200 OK INVITE (sendrecv) 








ACK 


^ 


CASED 


^ 


UPDATE (sendonly) 








200 OK UPDATE (recvonly) 


^ 






UPDATE (inactive) 


^ 




^ 


200 OK UPDATE (inactive) 






^ 


UPDATE (sendonly) 








200 OK UPDATE (recvonly) 


^ 






UPDATE (sendrecv) 


^ 




^ 


200 OK UPDATE (sendrecv) 
Apply post test routine 
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Comments 


Check: Is the user in network B able to set the session on hold by sending an 

INVITE or UPDATE request and the version parameter in the SDP 'o' 

line is incremented? 
Check: Is the user in network A able to set the session on hold by sending an 

INVITE or UPDATE request and the version parameter in the SDP 'o' 

line is incremented? 
Check: Is the user in network B able to retrieve the session by sending an 

INVITE or UPDATE request and the version parameter in the SDP 'o' 

line is incremented? 
Check: Is the user in network A able to retrieve the session by sending an 

INVITE or UPDATE request and the version parameter in the SDP 'o' 

line is incremented? The absence of the 'sendrecv' attribute is the 

default value. 
Repeat this test in reverse direction. 



Test case number 


SS hold 011 


Test case group 


SIP-SIP/Service/HOLD 


Reference 


B.10/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 54 


Test purpose 


SIP-I support. Hold requested by the calling user. 

Ensure that when an INVITE request updates a confirmed session a CPG is 
encapsulated if ISUP - SIP-I interworking is applicable in Network A. The 
Generic Notification Indicator parameter is present set to 'hold'. The 'a' attribute 
is set to 'sendonly' present in the SDP. 
In the 200 OK INVITE the 'a' attribute is set to 'recvonly' present in the SDP. 


Configuration 




SIP Parameter 


NVITE 

Content-Type: multipart/mixed;boundary=[any boundary name] 

--[any boundary name] 

a=sendonly 

--[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

CPG 

Generic notification 
remote hold 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

A confirmed session already exists 
CASE A INVITE(sendonly, CPG hold) ^ 

^ 200 OK INVITE (recvonly) 

ACK ^ 
Apply post test routine 


Comments 


Establish a session from Network A to Network B 

The user in the PSTN/PLMN part of Network A places the session on hold. 

Check: Is a CPG encapsulated in the INVITE request? 

Check: Is a Generic notification parameter present the Notification indicator 

set to remote hold'? 
Check: Is the 'a' attribute in the SDP set to 'sendonly'? 
Check: Is the Version parameter in the SDP incremented? 
Repeat this test in reverse direction. 
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Test case number 


SS hold 012 


Test case group 


SIP-SIP/Service/HOLD 


Reference 


B.10/[24] 


SELECTION EXPRESSION 


[Network B] SE 17 AND SE 47 AND SE 54 


Test purpose 


SIP-I support. Hold requested by the called user. 

Ensure that when an INVITE request updates a confirmed session a CPG is 
encapsulated if SIP-I - ISUP interworking is applicable in Network B. The 
Generic Notification Indicator parameter is present set to 'hold'. The 'a' attribute 
is set to 'sendonly' present in the SDP. 
In the 200 OK INVITE the 'a' attribute is set to 'recvonly' present in the SDP. 


Configuration 




SIP Parameter 


INVITE: 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

a=sendonly 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

CPG 

Generic notification 
remote hold 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

A confirmed session already exists 
CASE A ^ INVITE(sendonly, CPG hold) 

200 OK INVITE (recvonly) ^ 
^ ACK 

Apply post test routine 


Comments 


Establish a session from Network A to Network B 

The user in the PSTN/PLMN part of Network B places the session on hold. 

Check: Is a CPG encapsulated in the INVITE request? 

Check: Is a Generic notification parameter present the Notification indicator 

set to remote hold'? 
Check: Is the 'a' attribute in the SDP set to 'sendonly'? 
Check: Is the Version parameter in the SDP incremented? 
Repeat this test in reverse direction. 



ETSI 



87 



ETSI TS 101 585 VI .1.2 (2012-09) 



Test case number 


SS hold 013 


Test case group 


SIP-SIP/Service/HOLD 


Reference 


B.10/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 54 


Test purpose 


SIP-I support. Hold requested by the originating user, Hold by the 
terminating user. Retrieve requested by the originating user. 

Ensure the hold and retrieve procedure when ISUP - SIP-I interworking applies 
in the Network A: 

• Originating user in Network A places the session on hold. 

• Terminating user in Network B places the session on hold. 

• Originating user in Network A retrieves the session. 

• Terminating user in Network B retrieves the session. 

Verify the Generic notification parameter in the encapsulated CPG present in the 
INVITE request from the Network A. 


Configuration 




SIP Parameter 


INVITE: 

Content-Type: multipart/mixed;boundary=[any boundary name] 

--[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
CPG 

Generic notification 
remote hold 

or 
remote retrieval 
-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

A confirmed session already exists 
CASE A INVITE(sendonly, CPG hold) ^ 

^ 200 OK INVITE (recvonly) 

ACK ^ 

^ INVITE(inactive) 

200 OK INVITE (inactive) ^ 
^ ACK 

INVITE(sendonly, CPG retrieval) ^ 
^ 200 OK INVITE (recvonly) 

ACK ^ 

^ INVITE(sendrecv) 

200 OK INVITE (sendrecv) ^ 

^ ACK 

Apply post test routine 


Comments 


Establish a session from Network A to Network B 

The user in the PSTN/PLMN part of Network A places the session on hold. 

Check: Is a CPG encapsulated in the INVITE request? 

Check: Is a Generic notification parameter present the Notification indicator 

set to remote hold? 
Check: Is the 'a' attribute in the SDP set to 'sendonly'? 
Check: Is the Version parameter in the SDP incremented? 
The user in Network B places the session on hold 
Check: Is the 'a' attribute in the SDP set to 'inactive'? 
Check: Is the Version parameter in the SDP incremented? 
The user in Network A retrieves the session 
Check: Is a CPG encapsulated in the INVITE request? 
Check: Is a Generic notification parameter present the Notification indicator 

set to remote retrieval? 
Check: Is the 'a' attribute in the SDP set to 'sendonly'? 
Check: Is the Version parameter in the SDP incremented? 
The user in Network B retrieves the session 
Check: Is the 'a' attribute in the SDP set to 'sendrecv'? 
Check: Is the Version parameter in the SDP incremented? 
Repeat this test in reverse direction. 
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Test case number 


SS hold 014 


Test case group 


SIP-SIP/Service/HOLD 


Reference 


B.10/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 54 


Test purpose 


SIP-I support. Hold requested by the originating user, Hold by the 
terminating user. Retrieve requested by the terminating user. 

Ensure the hold and retrieve procedure when ISUP - SIP-I interworking applies 
in the Network A: 

• Originating user in Network A places the session on hold. 

• Terminating user in Network B places the session on hold. 

• Terminating user in Network B retrieves the session. 

• Originating user in Network A retrieves the session. 

Verify the Generic notification parameter in the encapsulated CPG present in the 
INVITE request from the Network A. 


Configuration 




SIP Parameter 


INVITE: 

Content-Type: multipart/mixed;boundary=[any boundary name] 

--[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
CPG 

Generic notification 
remote hold 

or 
remote retrieval 
-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

A confirmed session already exists 

INVITE(sendonly, CPG hold) ^ 
^ 200 OK INVITE (recvonly) 

ACK ^ 

^ INVITE(inactive) 

200 OK INVITE (inactive) ^ 
^ ACK 

^ INVITE(recvonly) 

200 OK INVITE (sendonly) ^ 
^ ACK 

INVITE(sendrecv, CPG retrieval) ^ 
^ 200 OK INVITE (sendrecv) 

ACK ^ 
Apply post test routine 


Comments 


Establish a session from Network A to Network B 

The user in the PSTN/PLMN part of Network A places the session on hold. 

Check: Is a CPG encapsulated in the INVITE request? 

Check: Is a Generic notification parameter present the Notification indicator 

set to remote hold? 
Check: Is the 'a' attribute in the SDP set to 'sendonly'? 
Check: Is the Version parameter in the SDP incremented? 
The user in Network B places the session on hold 
Check: Is the 'a' attribute in the SDP set to 'inactive'? 
Check: Is the Version parameter in the SDP incremented? 
The user in Network B retrieves the session 
Check: Is the 'a' attribute in the SDP set to 'recvonly'? 
Check: Is the Version parameter in the SDP incremented? 
The user in Network A retrieves the session 
Check: Is a CPG encapsulated in the INVITE request? 
Check: Is a Generic notification parameter present the Notification indicator 

set to remote retrieval? 
Check: Is the 'a' attribute in the SDP set to 'sendrecv'? 
Check: Is the Version parameter in the SDP incremented? 
Repeat this test in reverse direction. 
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Test case number 


SS hold 015 


Test case group 


SIP-SIP/Service/HOLD 


Reference 


B.10/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 54 


Test purpose 


SIP-I support. Hold requested by the terminating user, Hold by the 
originating user. Retrieve requested by the originating user. 

Ensure the hold and retrieve procedure when ISUP - SIP-I interworking applies 
in the Network A: 

• Terminating user in Network B places the session on hold. 

• Originating user in Network A places the session on hold. 

• Originating user in Network A retrieves the session. 

• Terminating user in Network B retrieves the session. 

Verify the Generic notification parameter in the encapsulated CPG present in the 
INVITE request from the Network A. 


Configuration 




SIP Parameter 


INVITE: 

Content-Type: multipart/mixed;boundary=[any boundary name] 

--[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
CPG 

Generic notification 
remote hold 

or 
remote retrieval 
-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

A confirmed session already exists 

^ INVITE(sendonly) 

200 OK INVITE (recvonly) ^ 
^ ACK 

INVITE(inactive, CPG hold) ^ 
^ 200 OK INVITE (inactive) 

ACK ^ 

INVITE(recvonly, CPG retrieval) ^ 
^ 200 OK INVITE (sendonly) 

ACK ^ 

^ INVITE(sendrecv) 

200 OK INVITE (sendrecv) ^ 

^ ACK 

Apply post test routine 


Comments 


Establish a session from Network A to Network B 

The user in Network B places the session on hold. 

Check: Is the 'a' attribute in the SDP set to 'sendonly'? 

Check: Is the Version parameter in the SDP incremented? 

The user in Network A places the session on hold 

Check: Is a CPG encapsulated in the INVITE request? 

Check: Is a Generic notification parameter present the Notification indicator 

set to remote hold? 
Check: Is the 'a' attribute in the SDP set to 'inactive'? 
Check: Is the Version parameter in the SDP incremented? 
The user in Network A retrieves the session 
Check: Is a CPG encapsulated in the INVITE request? 
Check: Is a Generic notification parameter present the Notification indicator 

set to remote retrieval? 
Check: Is the 'a' attribute in the SDP set to 'recvonly'? 
Check: Is the Version parameter in the SDP incremented? 
The user in Network B retrieves the session 
Check: Is the 'a' attribute in the SDP set to 'sendrecv'? 
Check: Is the Version parameter in the SDP incremented? 
Repeat this test in reverse direction. 
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Test case number 


SS hold 016 


Test case group 


SIP-SIP/Service/HOLD 


Reference 


B.10/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 54 


Test purpose 


SIP-I support. Hold requested by the terminating user, Hold by the 
originating user. Retrieve requested by the terminating user. 

Ensure the hold and retrieve procedure when ISUP - SIP-I interworking applies 
in the Network A: 

• Terminating user in Network B places the session on hold. 

• Originating user in Network A places the session on hold. 

• Terminating user in Network B retrieves the session. 

• Originating user in Network A retrieves the session. 

Verify the Generic notification parameter in the encapsulated CPG present in the 
INVITE request from the Network A. 


Configuration 




SIP Parameter 


INVITE: 

Content-Type: multipart/mixed;boundary=[any boundary name] 

--[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
CPG 

Generic notification 
remote hold 

or 
remote retrieval 
-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

A confirmed session already exists 

^ INVITE(sendonly) 

200 OK INVITE (recvonly) ^ 
^ ACK 

INVITE(inactive, CPG hold) ^ 
^ 200 OK INVITE (inactive) 

ACK ^ 

^ INVITE(sendonly) 

200 OK INVITE (recvonly) ^ 
^ ACK 

INVITE(sendrecv, CPG retrieval) ^ 
^ 200 OK INVITE (sendrecv) 

ACK ^ 
Apply post test routine 


Comments 


Establish a session from Network A to Network B 

The user in Network B places the session on hold. 

Check: Is the 'a' attribute in the SDP set to 'sendonly'? 

Check: Is the Version parameter in the SDP incremented? 

The user in Network A places the session on hold 

Check: Is a CPG encapsulated in the INVITE request? 

Check: Is a Generic notification parameter present the Notification indicator 

set to remote hold? 
Check: Is the 'a' attribute in the SDP set to 'inactive'? 
Check: Is the Version parameter in the SDP incremented? 
The user in Network B retrieves the session 
Check: Is the 'a' attribute in the SDP set to 'sendonly'? 
Check: Is the Version parameter in the SDP incremented? 
The user in Network A retrieves the session 
Check: Is a CPG encapsulated in the INVITE request? 
Check: Is a Generic notification parameter present the Notification indicator 

set to remote retrieval? 
Check: Is the 'a' attribute in the SDP set to 'sendrecv'? 
Check: Is the Version parameter in the SDP incremented? 
Repeat this test in reverse direction. 



ETSI 



91 



ETSI TS 101 585 VI .1.2 (2012-09) 



7.1.5.6 



Communication Diversion (CDIV) 



7.1.5.6.1 



Communication Forwarding Unconditional (CFU) 



Test case number 


SS cfu 001 


Test case group 


SIP-SIP/Service/CFU 


Reference 


4.5.2.6/f9] 


SELECTION EXPRESSION 


SE25 


Test purpose 


Communication forwarding unconditional, basic rules. 

The user A and user C are in Network A. The user B is in network B and is 
provided with CFU. 

Ensure that when user A calls user B, the call is forwarded unconditional to user 
C. In the active call state, ensure the property of speech. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFU is performecJ 
^ INVITE(Call-ID B-C) 

180Ringing(Call-IDC-B) ^ 
^ 180Ringing(Call-IDB-A) 

200 OK INVITE(Call-ID C-B) ^ 
^ ACK(Call-ID B-C) 
^ 200 OK INVITE(Call-ID B-A) 

ACK(Call-ID A-B) ^ 
Communication 
Apply post test routine 


Comments 


Check: CDIV unconditional is successful. 

Check: In the active call state, ensure the property of speech. 

Check: Is the P-Asserted-ldentity present set to the identity of the originating 

user? 
Repeat this test in reverse direction. 



Test case number 


SS cfu 002 


Test case group 


SIP-SIP/Service/CFU 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE 25 AND SE 30 


Test purpose 


Communication forwarding unconditional, no notification. 

The user A and user C are in Network A. The user B is in network B and is 
provided with CFU, subscription option: Originating user receives notification that 
his communication has been diverted = No. 

Ensure that when user A calls user B, the call is forwarded unconditional to user 
C, the originating user is not notified. 


Configuration 


Subscription options: 


unginating user receives notification that his communication nas oeen aiverteq = 
No 


SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFU is performed 
^ INVITE(Call-ID B-C) 

180Ringing(Call-IDC-B) ^ 
^ 180Ringing(Call-IDB-A) 
Apply post test routine 


Comments 


Check: No notification regarding call forwarding in network B is received at the 

interconnection interface. 
Repeat this test in reverse direction. 
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Test case number 


SS cfu 003 


Test case group 


SIP-SIP/Service/CFU 


Reference 


4.5.2.6/f91 


SELECTION EXPRESSION 


SE 25 AND SE 30 


Test purpose 


Communication forwarding unconditional, originating user is notified. URI 
of the diverted-to user not received. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFU Originating user receives notification that his communication 
has been diverted = Yes and ("Served user allows the presentation of forwarded 
to URI to originating user in diversion notification" =No and. "Served user allows 
the presentation of his/her URI to originating user in diversion notification" = No. 
Ensure that when user A calls user B, the call is forwarded unconditional to user 
0, user A is notified of call diversion and not informed of the diverted-to number 
and served user number. 


Configuration 


Subscription options: 

• Originating user receives notification that his communication has been 
diverted = Yes 

• Served user allows the presentation of forwarded to URI to originating use| 
in diversion notification = No 

• Served user allows the presentation of his/her URI to originating user in 
diversion notification = No 


SIP Parameter 


p81 Being Forwarded 

History-Info: 

<sip:userB@networkB?Privacy=history>;index=1, 

<sip: userG@networkA;cause=302?Privacy=history>;index=1 .1 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFU is performed 
^ INVITE(Call-ID B-C) 
^ p1 Being Forwarded(Call-ID B-A) 
Apply post test routine 


Comments 


Check: A 181 Being Forwarded and a History-Info header is received at the 
interconnection interface in both entries in the History-Info header a 
Privacy header is escaped value 'history'. 

Check: Is the cause parameter in the last entry is set to '302' 

NOTE: The history entries can be accumulated in "one" History-Info header or 
each history entry is present in one single History-Info header. 

Repeat this test in reverse direction. 
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Test case number 


SS cfu 004 


Test case group 


SIP-SIP/Service/CFU 


Reference 


4.5.2.6/f91 


SELECTION EXPRESSION 


SE 25 AND SE 30 


Test purpose 


Communication forwarding unconditional, originating user is notified. URI 
from the diverted-to user received. 

The user A and user C are in network 1 . The user B is in network N2 and is 
provided with CFU Originating user receives notification that his communication 
has been diverted = Yes and "Served user allows the presentation of forwarded 
to URI to originating user in diversion notification" = Yes. 
Ensure that when user A calls user B, the call is forwarded unconditional to user 
0, user A is notified of call diversion and informed of the diverted-to number. 


Configuration 


Subscription options: 

• Originating user receives notification that his communication has been 
diverted = Yes 

• Served user allows the presentation of forwarded to URI to originating usq| 
in diversion notification = Yes 


SIP Parameter 


,181 Being Forwarded 
History-Info: 

<sip:userB@networkB>;index= 1 , 

<sip: userG@networkA;cause=302>;index=1 .1 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFU is performed 
^ INVITE(Call-ID B-C) 
^ TCTBeing Forwarded(Call-ID B-A) 
Apply post test routine 


Comments 


Check: A 181 Being Forwarded is received at the interconnection interface 
Check: A History-Info header is contained in the 181 with the URI of the 

diverted-to user. 
Check: Is the cause parameter in the last entry is set to '302'? 
NOTE: The history entries can be accumulated in "one" History-Info header or 

each history entry is present in one single History-Info header. 
Repeat this test in reverse direction. 
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Test case number 


SS cfu 005 


Test case group 


SIP-SIP/Service/CFU 


Reference 


4.5.2.6/f91 


SELECTION EXPRESSION 


SE 25 AND SE 30 


Test purpose 


Communication forwarding unconditional, diverted-to user does not 
receive the URI of the served user. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFU "Served user allows the presentation of his/her URI to the 
diverted-to user"= No. 

Ensure that when user A calls user B, the call is forwarded unconditional to user 
0, user is not informed of the forwarding number. 


Configuration 


Subscription options: 

• Served user allows the presentation of his/her URI to the diverted-to user = 
No 


SIP Parameter 


INVITE: 

Request line contains ';cause=302' 

History-Info header: 

<sip:userB@networkB?Privacy=history>;index=1, 
<sip: userG@networkA;cause=302>;index=1 .1 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFU is performed 
^ INVITE(Call-ID B-C) 
Apply post test routine 


Comments 


Check: A History-Info header is received in the INVITE contains the URI of 
user B (served user) at the interconnection interface and a Privacy 
header is escaped set to 'history'. 

Check: Is the 'cause' parameter present in the Request line sent to user C 
(diverted-to user) set to '302'? 

Check: Is the cause parameter in the last entry is set to '302'? 

NOTE: The history entries can be accumulated in "one" History-Info header or 
each history entry is present in one single History-Info header. 

Repeat this test in reverse direction. 
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Test case number 


SS cfu 006 


Test case group 


SIP-SIP/Service/CFU 


Reference 


4.5.2.6/f91 


SELECTION EXPRESSION 


SE 25 AND SE 30 


Test purpose 


Communication forwarding unconditional, diverted-to user receives the 
URI of the served user. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFU "Served user allows the presentation of his/her URI to 
diverted-to user" = Yes. 

Ensure that when user A calls user B, the call is forwarded unconditional to user 
0, user is informed of the forwarding number. 


Configuration 


Subscription options: 

• Served user allows the presentation of his/her URI to diverted-to user = ^W 


SIP Parameter 


INVITE: 

Request line contains ';cause=302' 

History-Info header: 

<sip:userB@networkB>;index=1 , 

<sip: userC@networkA;cause=302>;index=1 .1 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFU is performed 
^ INVITE(Call-ID B-C) 
Apply post test routine 


Comments 


Check: A History-Info header is received in the INVITE contains the URI of 
user B (served user) at the interconnection interface. 

Check: Is the 'cause' parameter present in the Request line sent to user C 
(diverted-to user) set to '302'? 

Check: Is the cause parameter in the last entry is set to '302'? 

NOTE: The history entries can be accumulated in "one" History-Info header or 
each history entry is present in one single History-Info header. 

Repeat this test in reverse direction. 
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Test case number 


SS cfu 007 


Test case group 


SIP-SIP/Service/CFU 


Reference 


4.5.2.6/f91 


SELECTION EXPRESSION 


SE 25 AND SE 30 


Test purpose 


Communication forwarding unconditional, full notification. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFU Originating user receives notification that his communication 
has been diverted = Yes and ("Served user allows the presentation of forwarded 
to URI to originating user in diversion notification" = Yes, and "Served user 
allows the presentation of his/her URI to diverted-to user" = Yes. 
Ensure that when user A calls user B, the call is forwarded unconditional to user 
C, user A is notified of call diversion and informed of the diverted-to number and 
user C is informed of the forwarding number. 


Configuration 


Subscription options: 


• unginating user receives notiTication mat nis communicaTion has been 
diverted = Yes 

• Served user allows the presentation of forwarded to URI to originating user 
in diversion notification = Yes 

• Served user allows the presentation of his/her URI to diverted-to user = Yes 


SIP Parameter 


INVITE: 

Request line contains ';cause=302' 

History-Info header: 

<sip:userB@networkB>;index=1 , 

<sip: userC@networkA;cause=302>;index=1 .1 

^^^eing Forwarded 
History-Info header: 

<sip:userB@networkB>;index=1 , 

<sip: userC@networkA;cause=408>;index=1 .f 

poo OK INVITE 
History-Info header: 

<sip:userB@networkB>;index=1 , 

<sip: userC@networkA;cause=486>;index=1 .1 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFU is performed 

^ INVITE(Call-ID B-C) 

^ ^Hping Forwarcfl(Call-ID B-A 

180Ringing(Call-IDC-B) ^ 
^ 180Ringing(Call-IDB-A) 

200 OK INVITE(Call-ID C-B) ^ 
^ ACK(Call-ID C-B) 
^ 200 OK INVITE(Call-ID B-A) 

ACK(Call-IDA-B) ^ 
Communication 
Apply post test routine 


Comments 


Check: A History-Info header is received in the INVITE at the interconnection 

interface sent to user C containing the URI identifying the served user. 
Check: A History-Info header is received in the 181 Being Forwarded at the 

interconnection interface sent to user A containing the URI identifying 

the diverted-to user. 
Check: Is the 'cause' parameter present in the Request line sent to user C 

(diverted-to user) set to '302'? 
NOTE: The history entries can be accumulated in "one" History-Info header or 

each history entry is present in one single History-Info header. 
Repeat this test in reverse direction. 
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Test case number 


SS cfu 008 


Test case group 


SIP-SIP/Service/CFU 


Reference 


4.5.2.6/f9] 


SELECTION EXPRESSION 


SE25 


Test purpose 


Communication forwarding unconditional, unsuccessful UDUB. 

The user A and user are in network A. The user B is in network B and is 
provided with CFU. 

Ensure that when user A calls user B, the call is forwarded unconditional to user 
user is user determined user busy. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFU is performed 

^ INVITE(Call-ID B-C) 

486 Busy Here(Call-ID C-B) ^ 
^ ACK(Call-ID B-C) 
^ 486 Busy Here(Call-ID A-B) 

ACK(Call-IDA-B) ^ 


Comments 


Check: The dialogue is terminated by receiving a 486 Busy Here. 
Repeat this test in reverse direction. 



Test case number 


SS cfu 009 


Test case group 


SIP-SIP/Service/GFU 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE25 


Test purpose 


Communication forwarding unconditional, unsuccessful NDUB. 

The user A and user G are in network A. The user B is in network B. 

Ensure that when user A calls user B, the call is forwarded unconditional to user 

G and user G is network determined user busy. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFU is performed 

^ INVITE(Call-ID B-C) 

486 Busy Here(Gall-ID G-B) ^ 
^ AGK(Gall-ID B-G) 
^ 486 Busy Here(Gall-ID A-B) 

AGK(Gall-IDA-B) ^ 


Comments 


Check: The dialogue is terminated by receiving a 486 Busy Here. 
Repeat this test in reverse direction. 
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Test case number 


SS cfu 010 


Test case group 


SIP-SIP/Service/CFU 


Reference 


4.5.2.6/f9] 


SELECTION EXPRESSION 


SE 25 AND SE 30 AND [Network A] SE 9 


Test purpose 


Communication forwarding unconditional, interaction with a not trusted 
network. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFU Originating user receives notification that his communication 
has been diverted = Yes ("Served user allows the presentation of forwarded to 
URI to originating user in diversion notification"=Yes, "diverting number is 
released to the diverted-to user"=Yes. 

Ensure that when user A calls user B, the call is forwarded unconditional to user 
0, user A is notified of call diversion and not informed of the diverted-to number 
and user is not informed of the forwarding number. 


Configuration 


Subscription options: 


• 
• 
• 

• 


Originating user receives notification that his communication has been 

diverted = Yes 

Served user allows the presentation of forwarded to URI to originating us J 

in diversion notification = No 

Served user allows the presentation of his/her URI to originating user in 

diversion notification = No 

Served user allows the presentation of his/her URI to the diverted-to user = 


No 


SIP Parameter 


INVITE: no History-Info header 


181 Being Forwarded no History-Info header 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFU is performed 
^ INVITE(Call-ID B-C) 
^ p1 Being Forwarded(Call-ID B-A) 
Apply post test routine 


Comments 


Check: No History-Info header is received in the INVITE at the 

interconnection interface. 
Check: No History-Info header is received in the 181 Being Forwarded at the 

interconnection interface (if sent). 
Repeat this test in reverse direction. 
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Test case number 


SS cfu 011 


Test case group 


SIP-SIP/Service/CFU 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B] SE 17 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CFU performed in Network B, Notification subscription 
options is set to presentation not allowed. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 

of Network B and is provided with CFU, Calling user receives notification that his 

call has been diverted (forwarded or deflected) = yes, without diverted-to user 

number. 

Ensure that when user A calls user B, the call is forwarded unconditional to user 

C, user A is not notified about call diversion. 

The notification information is present in the encapsulated ACM contained in the 

Redirection number and Call diversion information if 

SIP-I - ISUP/BICC interworking is applicable in Network B. 


Configuration 


Subscription options: 


• Calling user receives notification that his call has been diverted (forwarde(i 
or deflected) = no 


SIP Parameter 


183 Session Progress 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

ACM 

Backward call indicator 

Called party's status indicator 
no indication 
Redirection number 

Address signal {Diverted-to user) 
Call diversion information 

Notification subscription options 

presentation not allowed 
Redirecting reason 
unconditional 
Generic notification 
call is diverting 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFU is performed 

^ INVITE(Call-ID B-C, lAM) 
^ 1 83 Session Progress (Call-ID B-A, ACM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 

performs the diversion to a user in Network A 

Check: Is a 183 Session Progress received at the interconnection interface? 

Check: Is an ACM encapsulated in the 1 83? 

Check: Is the Called party's status indicator set to 'no indication'? 

Check: Is the Redirection number present? 

Check: Is Notification subscription options indicator set to 'presentation not 

allowed'? 
Check: Is the Redirecting reason set to 'unconditional'? 
Repeat this test in reverse direction. 
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Test case number 


SS cfu 012 


Test case group 


SIP-SIP/Service/CFU 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B] SE 17 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CFU performed in Network B, Notification subscription 
options is set to presentation allowed without redirection number. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CFU, Calling user receives notification that his 
call has been diverted (forwarded or deflected) = yes, without diverted-to user 
number. 

Ensure that when user A calls user B, the call is forwarded unconditional to user 
C, user A is notified of call diversion and informed of the diverted-to number. 
The notification information is present in the encapsulated ACM contained in the 
Redirection number and Call diversion information if 
SIP-I - ISUP/BICC interworking is applicable in Network B. 


Configuration 


Subscription options: 


• Calling user receives notification that his call has been diverted (forwarde(i 
or deflected) = yes, without diverted-to user number 


SIP Parameter 


183 Session Progress 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

ACM 

Backward call indicator 

Called party's status indicator 
no indication 
Redirection number 

Address signal {Diverted-to user) 
Call diversion information 

Notification subscription options 

presentation allowed without redirection number 
Redirecting reason 
unconditional 
Generic notification 
call is diverting 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFU is performed 

^ INVITE(Call-ID B-C, lAM) 
^ 1 83 Session Progress (Call-ID B-A, ACM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 

performs the diversion to a user in Network A 

Check: 183 Session Progress is received at the interconnection interface. 

Check: Is an ACM encapsulated in the 1 83? 

Check: Is the Called party's status indicator set to 'no indication'? 

Check: Is the Redirection number present? 

Check: Is Notification subscription options indicator set to 'presentation 

allowed without redirection number'? 
Check: Is the Redirecting reason set to 'unconditional'? 
Repeat this test in reverse direction. 
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Test case number 


SS cfu 013 


Test case group 


SIP-SIP/Service/CFU 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B] SE 17 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CFU performed in Network B, Notification subscription 
options is set to presentation allowed with redirection number. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CFU, Calling user receives notification that his 
call has been diverted (forwarded or deflected) = yes, with diverted-to user 
number. 

Ensure that when user A calls user B, the call is forwarded unconditional to user 
C, user A is notified of call diversion and informed of the diverted-to number. 
The notification information is present in the encapsulated ACM contained in the 
Redirection number and Call diversion information if SIP-I - ISUP/BICC 
interworking is applicable in Network B. 


Configuration 


Subscription options: 


• Calling user receives notification that his call has been diverted (forwarde(i 
or deflected) = yes, with diverted-to user number 


SIP Parameter 


183 Session Progress 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

ACM 

Backward call indicator 

Called party's status indicator 
no indication 
Redirection number 

Address signal {Diverted-to user) 
Call diversion information 

Notification subscription options 


Redirecting reason 
unconditional 
Generic notification 
call is diverting 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFU is performed 

^ INVITE(Call-ID B-C, lAM) 
^ 1 83 Session Progress (Call-ID B-A, ACM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 

performs the diversion to a user in Network A 

Check: 183 Session Progress is received at the interconnection interface. 

Check: Is an ACM encapsulated in the 1 83? 

Check: Is the Called party's status indicator set to 'no indication'? 

Check: Is the Redirection number present? 

Check: Is Notification subscription options indicator set to 'presentation 

allowed with redirection number'? 
Check Is the Redirecting reason set to 'unconditional'? 
Repeat this test in reverse direction. 
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Test case number 


SS cfu 014 


Test case group 


SIP-SIP/Service/CFU 


Reference 


6.7/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 53 


Test purpose 


SIP-I support. CFU performed in Network B, Restriction of the Redirection 
number. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CFU, Diverted-to user is subscribed to the 
COLR service in Permanent mode. 

Ensure that when user A calls user B, the call is forwarded unconditional to user 
C, a Redirection number restriction parameter is present set to 'Presentation 
restricted' in the encapsulated ANM contained in the 200 OK INVITE if 
ISUP/BICC- SIP-I interworking is applicable in Network A. 


Configuration 


Subscription options: 

• Connected user subscribed to COLR, Permanent = yes 


SIP Parameter 


200 OK 


Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

ANM 

Redirection number restriction 
Presentation restricted 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B), lAM ^ 
CFU is performed 

^ INVITE(Call-ID B-C) 

1 80 Ringing (Call-ID C-B, ACM) ^ 
^ 180 Ringing (Call-ID B-A) 

200 OK INVITE (Call-ID C-B, ANM) ^ 
^ ACK (Call-ID B-C) 
^ 200 OK INVITE (Call-ID B-A) 

ACK (Call-ID A-B) ^ 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 

performs the diversion to a user in Network A 

Check: Is a 200 OK INVITE received at the interconnection interface? 

Check: Is an ANM encapsulated in the 200 OK? 

Check: Is the ISUP/BICC Redirection number restriction set to 'Presentation 

restricted'? 
Repeat this test in reverse direction. 
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Test case number 


SS cfu 015 


Test case group 


SIP-SIP/Service/CFU 


Reference 


6.7/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 53 


Test purpose 


SIP-I support. CFU performed in Network B, No restriction of the 
Redirection number. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CFU, Diverted-to user is not subscribed to the 
COLR service. 

Ensure that when user A calls user B, the call is forwarded unconditional to user 
C, if a Redirection number restriction parameter is present it is set to 
'Presentation allowed' in the encapsulated ANM contained in the 200 OK INVITE 
if ISUP/BICC- SIP-I interworking is applicable in Network A. 


Configuration 


Subscription options: 

• Connected user subscribed to COLR = ho 


SIP Parameter 


200 OK 


Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

ANM 

Redirection number restriction 
Presentation allowed 
or 
Redirection number restriction not present 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B), lAM ^ 
CFU is performed 

^ INVITE(Call-ID B-C) 

1 80 Ringing (Call-ID C-B, ACM) ^ 
^ 180 Ringing (Call-ID B-A) 

2flILQK INVITE (Call-ID C-B, ANM) ^ 
^ ACK (Call-ID B-C) 
^ 200 OK INVITE (Call-ID B-A) 

ACK (Call-ID A-B) ^ 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 

performs the diversion to a user in Network A 

Check: Is a 200 OK INVITE received at the interconnection interface? 

Check: Is an ANM encapsulated in the 200 OK? 

Check: Is the ISUP/BICC Redirection number restriction present set to 

'Presentation allowed' or is the parameter absent? 
Repeat this test in reverse direction. 
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Test case number 


SS cfu 016 


Test case group 


SIP-SIP/Service/GFU 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CFU performed in Network B, Notification of diverted-to user 
Redirecting number 'presentation allowed'. 

The user A and user G are in Network A. The user B is in the PSTN/PLIVIN part 
of Network B and is provided with GFU, Served user releases his/her number to 
diverted-to user = Release diverting number information. 
Ensure that when user A calls user B, the call is forwarded unconditional to user 
G, user G is notified of call diversion and informed of the diverting number. 
The notification information is present in the encapsulated lAM contained in the 
Redirecting number 'presentation allowed' and Redirection information if 
ISUP/BIGG - SIP-I interworking is applicable in Network B. 


Configuration 


Subscription options: 

• Served user releases his/her number to diverted-to user = Release diverting 
number information 


SIP Parameter 


Gontent-Type: multipart/mixed;boundary=[any boundary name] 

--[any boundary name] 

Gontent-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

lAM 

Redirecting number 

Address presentation restricted indicator 

presentation allowed 
Address signal (Diverting user) 
Original called number 

Address presentation restricted indicator 

presentation allowed 
Address signal 
Redirection information 

Original Redirection Reason 

unknown 
Redirecting indicator 
Redirection counter 
Redirecting reason 

unconditional 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFU is performed 
^ ^^(Gall-ID B-G, lAM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 

performs the diversion to a user in Network A 

Check: Is a INVITE request received at the interconnection interface? 

Check: Is an lAM encapsulated in the INVITE? 

Check: Is the Redirecting number present and the Address presentation 

restricted indicator is set to 'presentation allowed'? 
Check: Is the Original called number present and the Address presentation 

restricted indicator is set to 'presentation allowed'? 
Check: Is the Redirection number present? 
Check: Is Redirection information present and the Redirecting reason is set to 

'unconditional'? 
Repeat this test in reverse direction. 
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Test case number 


SS cfu 017 


Test case group 


SIP-SIP/Service/GFU 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CFU performed in Network B, Notification of diverted-to user 
Redirecting number 'presentation restricted'. 

The user A and user G are in Network A. The user B is in the PSTN/PLIVIN part 
of Network B and is provided with GFU, Served user releases his/her number to 
diverted-to user = Release diverting number information. 
Ensure that when user A calls user B, the call is forwarded unconditional to user 
G, user G is notified of call diversion and informed of the diverting number. 
The notification information is present in the encapsulated lAM contained in the 
Redirecting number 'presentation restricted' and Redirection information if 
ISUP/BIGG - SIP-I interworking is applicable in Network B. 


Configuration 


Subscription options: 

• Served user releases his/her number to diverted-to user = Do not release 
diverting numberinformation 


SIP Parameter 


Gontent-Type: multipart/mixed;boundary=[any boundary name] 

--[any boundary name] 

Gontent-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

lAM 

Redirecting number 

Address presentation restricted indicator 

presentation restricted 
Address signal (Diverting user) 
Original called number 

Address presentation restricted indicator 

presentation restricted 
Address signal 
Redirection information 

Original Redirection Reason 

unknown 
Redirecting indicator 
Redirection counter 
Redirecting reason 

unconditional 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFU is performed 
^ ^^(Gall-ID B-G, lAM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 

performs the diversion to a user in Network A 

Check: Is a INVITE request received at the interconnection interface? 

Check: Is an lAM encapsulated in the INVITE? 

Check: Is the Redirecting number present and the Address presentation 

restricted indicator is set to 'presentation restricted'? 
Check: Is the Original called number present and the Address presentation 

restricted indicator is set to 'presentation restricted'? 
Check: Is the Redirection number present? 
Check: Is Redirection information present and the Redirecting reason is set to 

'unconditional'? 
Repeat this test in reverse direction. 
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7.1.5.6.2 



Communication Forwarding Busy (CFB) 



Test case number 


SS cfb 001 


Test case group 


SIP-SIP/Service/CFB 


Reference 


4.5.2.6/f91 


SELECTION EXPRESSION 


SE26 


Test purpose 


Communication forwarding busy, basic rules. 

The user A and user C are in Network A. The user B is in network B and is 
provided with CFB. 

Ensure that when user A calls user B, the call is forwarded busy to user C. In the 
active call state, ensure the property of speech. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFB is performed 
^ INVITE(Call-ID B-C) 

180Ringing(Call-IDC-B) ^ 
^ 180Ringing(Call-IDB-A) 

200 OK INVITE(Call-ID C-B) ^ 
^ ACK(Call-ID B-C) 
^ 200 OK INVITE(Call-ID B-A) 

ACK(Call-ID A-B) ^ 
Communication 
Apply post test routine 


Comments 


Check: CDIV busy is successful. 

Check: In the active call state, ensure the property of speech. 

Check: Is the P-Asserted-ldentity present set to the identity of the originating 

user? 
Repeat this test in reverse direction. 



Test case number 


SS cfb 002 


Test case group 


SIP-SIP/Service/CFB 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE26ANDSE30 


Test purpose 


Communication forwarding busy, no notification. 

The user A and user C are in Network A. The user B is in network B and is 
provided with CFB, subscription option: Originating user receives notification that 
his communication has been diverted = No. 

Ensure that when user A calls user B, the call is forwarded busy to user C, 
originating user is not notified. 


Configuration 


Subscription options: 

• Originating user receives notification that his communication has been 
diverted = No 


SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFB is performed 
^ INVITE(Call-ID B-C) 

180 Ringing(Call-ID C-B) ^ 
^ 180Ringing(Call-IDB-A) 
Apply post test routine 


Comments 


Check: No notification regarding call forwarding in network B is received at the 

interconnection interface. 
Repeat this test in reverse direction. 
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Test case number 


SS cfb 003 


Test case group 


SIP-SIP/Service/CFB 


Reference 


4.5.2.6/f91 


SELECTION EXPRESSION 


SE 26 AND SE 30 


Test purpose 


Communication forwarding busy, originating user is notified. URI from the 
served user not received. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFB Originating user receives notification that his communication 
has been diverted = Yes ("Served user allows the presentation of forwarded to 
URI to originating user in diversion notification" = No and. "Served user allows 
the presentation of his/her URI to originating user in diversion notification" = No. 
Ensure that when user A calls user B, the call is forwarded busy to user 0, user 
A is notified of call diversion and not informed of the diverted-to number and 
served user number. 


Configuration 


Subscription options: 


• 
• 
• 


Originating user receives notification that his communication has been 

diverted = Yes 

Served user allows the presentation of forwarded to URI to originating us J 

in diversion notification = No 

Served user allows the presentation of his/her URI to originating user in 

diversion notification = No 


SIP Parameter 


^81 Being Forwarded 


<sip:userB@networkB?Privacy=history&Reason=SIP;cause=486>;index=1, 
<sip: userC@networkA;cause=486?Pr/Vacy=/7/sfory>;index=1 .1 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFB is performed 

^ INVITE(Call-ID B-C) 

^ iatPeing Forwarded(Call-ID B-A) 

180Ringing(Call-IDC-B) ^ 
^ 180Ringing(Call-IDB-A) 
Apply post test routine 


Comments 


Check: A 181 Being Forwarded and a History-Info header is received at the 
interconnection interface in both entries in the History-Info header a 
Privacy header is escaped value 'history'. 

Check: Is the cause parameter in the last entry set to '486'? 

NOTE: The history entries can be accumulated in "one" History-Info header or 
each history entry is present in one single History-Info header. 

Repeat this test in reverse direction. 



ETSI 



108 



ETSI TS 101 585 VI .1.2 (2012-09) 



Test case number 


SS cfb 004 


Test case group 


SIP-SIP/Service/CFB 


Reference 


4.5.2.6/f91 


SELECTION EXPRESSION 


SE 26 AND SE 30 


Test purpose 


Communication forwarding busy, originating user is notified. URI from the 
diverted-to user received. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFB Originating user receives notification that his communication 
has been diverted = Yes ("Served user allows the presentation of forwarded to 
URI to originating user in diversion notification" =Yes. 

Ensure that when user A calls user B, the call is forwarded busy to user 0, user 
A is notified of call diversion and informed of the diverted-to number. 


Configuration 


Subscription options: 

• Originating user receives notification that his communication has been 
diverted = Yes 

• Served user allows the presentation of forwarded to URI to originating usq| 
in diversion notification =Y J 


SIP Parameter 


181 Being Forwarded 

<sip:userB@networkB?Reason=S\P; cause=486>;index= 1, 
<sip: userG@networkA;cause=486>;index=1 .1 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFB is performed 

^ INVITE(Call-ID B-C) 

^ 181 Being Forwarded(Call-ID B-A) 

180Ringing(Call-IDC-B) ^ 
^ 180Ringing(Call-IDB-A) 
Apply post test routine 


Comments 


Check: A 181 Being Forwarded is received at interconnection interface. 
Check: A History-Info header is contained in the 181 with the URI of the 

diverted-to user. 
Check: Is the cause parameter in the last entry set to '486'? 
NOTE: The history entries can be accumulated in "one" History-Info header or 

each history entry is present in one single History-Info header. 
Repeat this test in reverse direction. 
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Test case number 


SS cfb 005 


Test case group 


SIP-SIP/Service/CFB 


Reference 


4.5.2.6/f91 


SELECTION EXPRESSION 


SE 26 AND SE 30 


Test purpose 


Communication forwarding busy, diverted-to user does not receive the URI 
of the served user. 

The user A and user C are in network C. The user B is in network B and is 
provided with CFB "Served user allows the presentation of his/her URI to the 
diverted-to user" = No. 

Ensure that when user A calls user B, the call is forwarded busy to user 0, user 
is not informed of the forwarding number. 


Configuration 


Subscription options: 

• Served user allows the presentation of his/her URI to the diverted-to user = 
No 


SIP Parameter 


INVITE: 

Request line contains ';cause=486' 

History-Info header: 

<sip:userB@networkB?Privacy=history&Reason=SIP;cause=486>;index=1, 

<sip: userG@networkA;cause=486>;index=1 .1 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFB is performed 
^ INVITE(Call-ID B-C) 
Apply post test routine 


Comments 


Check: A History-Info header is received in the INVITE contains the URI of 
user B (served user) at the interconnection interface and a Privacy 
header is escaped set to 'history'. 

Check: Is the 'cause' parameter present in the Request line sent to user C 
(diverted-to user) set to '486'? 

Check: Is the cause parameter in the last entry set to '486'? 

NOTE: The history entries can be accumulated in "one" History-Info header or 
each history entry is present in one single History-Info header. 

Repeat this test in reverse direction. 
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Test case number 


SS cfb 006 


Test case group 


SIP-SIP/Service/CFB 


Reference 


4.5.2.6/f91 


SELECTION EXPRESSION 


SE 26 AND SE 30 


Test purpose 


Communication forwarding busy, diverted-to user receives the URI of the 
served user. 

The user A and user C are in network C. The user B is in network B and is 
provided with CFB "Served user allows the presentation of his/her URI to the 
diverted-to user" = Yes. 

Ensure that when user A calls user B, the call is forwarded busy to user 0, user 
is informed of the forwarding number. 


Configuration 


Subscription options: 

• Served user allows the presentation of his/her URI to the diverted-to user = 
Yes 


SIP Parameter 


INVITE: 

Request line contains ';cause=486' 

History-Info header: 


<sip: userC@networkA;cause=486>;index=1 .1 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFB is performed 
^ INVITE(Call-ID B-C) 
Apply post test routine 


Comments 


Check: A History-Info header is received in the INVITE contains the URI of 
user B (served user) at the interconnection interface. 

Check: Is the 'cause' parameter present in the Request line sent to user C 
(diverted-to user) set to '486'? 

Check: Is the cause parameter in the last entry set to '486'? 

NOTE: The history entries can be accumulated in "one" History-Info header or 
each history entry is present in one single History-Info header. 

Repeat this test in reverse direction. 
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Test case number 


SS cfb 007 


Test case group 


SIP-SIP/Service/CFB 


Reference 


4.5.2.6/f91 


SELECTION EXPRESSION 


SE 26 AND SE 30 


Test purpose 


Communication forwarding busy, full notification. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFB Originating user receives notification that his communication 
has been diverted = Yes ("Served user allows the presentation of forwarded to 
URI to originating user in diversion notification"= Yes, "diverting number is 
released to the diverted-to user" =Yes. 

Ensure that when user A calls user B, the call is forwarded busy to user C, user 
A is notified of call diversion and informed of the diverted-to number and user C 
is informed of the forwarding number. 


Configuration 


Subscription options: 


• 
• 

• 


unginating user receives notiTication mat nis communication nas Deen 

diverted = Yes 

Served user allows the presentation of forwarded to URI to originating user 

in diversion notification = Yes, 

diverting number is released to the diverted-to user = Yes 


SIP Parameter 


INVITE: 1 


Req 
Hist( 

< 
< 


uest line contains ';cause=486' 
Dry-info header: 


:sip:userB@networkB&Reason=SIP;cause=486>;index=l^ 
:sip: userC@networkA;cause=486>;index=1 .1 




^^feeina Forwarded 


History-Info header: 


<sip:userB@networkB&Reason=SIP;cause=486>;index=1, 
<sip: userC@networkA;cause=486>;index=1 .1 

|00 OK INVITE 

History-Info header: 

<sip:userB@networkB&Reason=SIP;cause=486>;index=1, 
<sip: userC@networkA;cause=486>;index=1 .1 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFB is performed 

^ INVITE(Call-ID B-C) 

^ ^Hping Forwarcfl(Call-ID B-A 

180Ringing(Call-IDC-B) ^ 
^ 180Ringing(Call-IDB-A) 

200 OK INVITE(Call-ID C-B) ^ 
^ ACK(Call-ID C-B) 
^ 200 OK INVITE(Call-ID B-A) 

ACK(Call-IDA-B) ^ 
Communication 
Apply post test routine 


Comments 


Check: A History-Info header is received in the INVITE at the interconnection 

interface sent to user C containing the URI identifying the served user. 
Check: A History-Info header is received in the 181 Being Forwarded at the 

interconnection interface sent to user A containing the URI identifying 

the diverted-to user. 
Check: Is the 'cause' parameter present in the Request line sent to user C 

(diverted-to user) set to '486'? 
Check: Is the cause parameter in the last entry set to '486'? 
NOTE: The history entries can be accumulated in "one" History-Info header or 

each history entry is present in one single History-Info header. 
Repeat this test in reverse direction. 
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Test case number 


SS cfb 008 


Test case group 


SIP-SIP/Service/CFB 


Reference 


4.5.2.6/f9] 


SELECTION EXPRESSION 


SE26 


Test purpose 


Communication forwarding busy, unsuccessful UDUB. 

The user A and user are in network A. The user B is in network B and is 
provided with CFB. 

Ensure that when user A calls user B, the call is forwarded busy to user and 
user is user determined user busy. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFB is performed 

^ INVITE(Call-ID B-C) 

486 Busy Here(Call-ID C-B) ^ 
^ ACK(Call-ID B-C) 
^ 486 Busy Here(Call-ID A-B) 

ACK(Call-IDA-B) ^ 


Comments 


Check: The dialogue is terminated by receiving a 486 Busy Here. 
Repeat this test in reverse direction. 



Test case number 


SS cfb 009 


Test case group 


SIP-SIP/Service/GFB 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE26 


Test purpose 


Communication forwarding busy, unsuccessful NDUB. 

The user A and user G are in network A. The user B is in network B and is 
provided with GFB. 

Ensure that when user A calls user B, the call is forwarded busy to user G and 
user G is network determined user busy. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFB is performed 

^ INVITE(Call-ID B-C) 

486 Busy Here(Gall-ID G-B) ^ 
^ AGK(Gall-ID B-G) 
^ 486 Busy Here(Gall-ID A-B) 

AGK(Gall-ID A-B) ^ 


Comments 


Check: A 181 Being Forwarded is received at network 1 originating access. 
Check: The dialogue is terminated by receiving a 486 Busy Here. 
Repeat this test in reverse direction. 
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Test case number 


SS cfb 010 


Test case group 


SIP-SIP/Service/CFB 


Reference 


4.5.2.6/f91 


SELECTION EXPRESSION 


SE 26 AND SE 30 AND [Network A] SE 9 


Test purpose 


Communication forwarding busy, interaction with a not trusted network. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFB Originating user receives notification that his communication 
has been diverted = Yes ("Served user allows the presentation of forwarded to 
URI to originating user in diversion notification"=Yes, "diverting number is 
released to the diverted-to user"=Yes. 

Ensure that when user A calls user B, the call is forwarded busy to user 0, user 
A is notified of call diversion and not informed of the diverted-to number and user 
is not informed of the forwarding number. 


Configuration 


Subscription options: 




unginating user receives notiTication that his communication nas Deen 

diverted = Yes 

Served user allows the presentation of forwarded to URI to originating user 

in diversion notification = No 

Served user allows the presentation of his/her URI to originating user in 

diversion notification = No 

Served user allows the presentation of his/her URI to the diverted-to user = 


No 


SIP Parameter 


INVITE: no History-Info header 


181 Being Forwarded no History-Info header 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFB is performed 
^ INVITE(Call-ID B-C) 
^ 181 Being Forwarded(Call-ID B-A) 
Apply post test routine 


Comments 


Check: No History-Info header is received in the INVITE at the interconnection 

interface. 
Check: No History-Info header is received in the 181 Being Forwarded at the 

interconnection interface (if sent). 
Repeat this test in reverse direction. 
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Test case number 


SS cfb 011 


Test case group 


SIP-SIP/Service/CFB 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CFB performed in Network B, Notification subscription 
options is set to presentation not allowed. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 

of Network B and is provided with CFB, Calling user receives notification that his 

call has been diverted (forwarded or deflected) = yes, without diverted-to user 

number. 

Ensure that when user A calls user B, the call is forwarded on busy user to user 

C, user A is not notified about call diversion. 

The notification information is present in the encapsulated ACM contained in the 

Redirection number and Call diversion information if SIP-I - ISUP/BICC 

interworking is applicable in Network B. 


Configuration 


Subscription options: 


• Calling user receives notification that his call has been diverted (forwarde(i 
or deflected) = no 


SIP Parameter 


183 Session Progress 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

ACM 

Backward call indicator 

Called party's status indicator 
no indication 
Redirection number 

Address signal {Diverted-to user) 
Call diversion information 

Notification subscription options 

presentation not allowed 
Redirecting reason 
User Busy 
Generic notification 
call is diverting 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFB is performed 

^ INVITE(Call-ID B-C, lAM) 
^ 1 83 Session Progress (Call-ID B-A, ACM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 

performs the diversion to a user in Network A 

Check: Is a 183 Session Progress received at the interconnection interface? 

Check: Is an ACM encapsulated in the 1 83? 

Check: Is the Called party's status indicator set to 'no indication'? 

Check: Is the Redirection number present? 

Check: Is Notification subscription options indicator set to 'presentation not 

allowed'? 
Check: Is the Redirecting reason set to User Busy'? 
Repeat this test in reverse direction. 



ETSI 



115 



ETSI TS 101 585 VI .1.2 (2012-09) 



Test case number 


SS cfb 012 


Test case group 


SIP-SIP/Service/CFB 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CFB performed in Network B, Notification subscription 
options is set to presentation allowed without redirection number. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CFB, Calling user receives notification that his 
call has been diverted (forwarded or deflected) = yes, without diverted-to user 
number. 

Ensure that when user A calls user B, the call is forwarded on busy user to user 
C, user A is notified of call diversion and informed of the diverted-to number. 
The notification information is present in the encapsulated ACM contained in the 
Redirection number and Call diversion information if SIP-I - ISUP/BICC 
interworking is applicable in Network B. 


Configuration 


Subscription options: 


• Calling user receives notification that his call has been diverted (forwarde(i 
or deflected) = yes, without diverted-to user number 


SIP Parameter 


183 Session Progress 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

ACM 

Backward call indicator 

Called party's status indicator 
no indication 
Redirection number 

Address signal {Diverted-to user) 
Call diversion information 

Notification subscription options 

presentation allowed without redirection number 
Redirecting reason 
User Busy 
Generic notification 
call is diverting 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFB is performed 

^ INVITE(Call-ID B-C, lAM) 
^ 1 83 Session Progress (Call-ID B-A, ACM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 

performs the diversion to a user in Network A 

Check: 183 Session Progress is received at the interconnection interface. 

Check: Is an ACM encapsulated in the 1 83? 

Check: Is the Called party's status indicator set to 'no indication'? 

Check: Is the Redirection number present? 

Check: Is Notification subscription options indicator is set to 'presentation 

allowed without redirection number'? 
Check: Is the Redirecting reason set to 'User Busy'? 
Repeat this test in reverse direction. 
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Test case number 


SS cfb 013 


Test case group 


SIP-SIP/Service/CFB 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CFB performed in Network B, Notification subscription 
options is set to presentation allowed with redirection number. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CFB, Calling user receives notification that his 
call has been diverted (forwarded or deflected) = yes, with diverted-to user 
number. 

Ensure that when user A calls user B, the call is forwarded on busy user to user 
C, user A is notified of call diversion and informed of the diverted-to number. 
The notification information is present in the encapsulated ACM contained in the 
Redirection number and Call diversion information if SIP-I - ISUP/BICC 
interworking is applicable in Network B. 


Configuration 


Subscription options: 


• Calling user receives notification that his call has been diverted (forwarde(i 
or deflected) = yes, with diverted-to user number 


SIP Parameter 


183 Session Progress 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

ACM 

Backward call indicator 

Called party's status indicator 
no indication 
Redirection number (Diverted-to user) 

Address signal 
Call diversion information 

Notification subscription options 


Redirecting reason 
User Busy 
Generic notification 
call is diverting 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFB is performed 

^ INVITE(Call-ID B-C, lAM) 
^ 1 83 Session Progress (Call-ID B-A, ACM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 

performs the diversion to a user in Network A 

Check: 183 Session Progress is received at the interconnection interface. 

Check: Is an ACM encapsulated in the 1 83? 

Check: Is the Called party's status indicator set to 'no indication'? 

Check: Is the Redirection number present? 

Check: Is Notification subscription options indicator is set to 'presentation 

allowed with redirection number'? 
Check: Is the Redirecting reason set to 'User Busy'? 
Repeat this test in reverse direction. 
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Test case number 


SS cfb 014 


Test case group 


SIP-SIP/Service/CFB 


Reference 


6.7/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 53 


Test purpose 


SIP-I support. CFB performed in Network B, Restriction of the Redirection 
number. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CFB, Diverted-to user is subscribed to the 
COLR service in Permanent mode. 

Ensure that when user A calls user B, the call is forwarded on busy user to user 
C, a Redirection number restriction parameter is present set to 'Presentation 
restricted' in the encapsulated ANM contained in the 200 OK INVITE if 
ISUP/BICC- SIP-I interworking is applicable in Network A. 


Configuration 


Subscription options: 

• Connected user subscribed to COLR, Permanent = yes 


SIP Parameter 


200 OK 


Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

ANM 

Redirection number restriction 
Presentation restricted 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B), lAM ^ 
CFB is performed 

4- INVITE(Call-ID B-C) 

1 80 Ringing (Call-ID C-B, ACM) ^ 
^ 180 Ringing (Call-ID B-A) 

200 OK INVITE (Call-ID C-B, ANM) ^ 
^ ACK (Call-ID B-C) 
^ 200 OK INVITE (Call-ID B-A) 

ACK (Call-ID A-B) ^ 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 

performs the diversion to a user in Network A 

Check: Is a 200 OK INVITE received at the interconnection interface? 

Check: Is an ANM encapsulated in the 200 OK? 

Check: Is the ISUP/BICC Redirection number restriction set to 'Presentation 

restricted'? 
Repeat this test in reverse direction. 
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Test case number 


SS cfb 015 


Test case group 


SIP-SIP/Service/CFB 


Reference 


6.7/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 53 


Test purpose 


SIP-I support. CFB performed in Network B, No restriction of the 
Redirection number. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CFB, Diverted-to user is not subscribed to the 
COLR service. 

Ensure that when user A calls user B, the call is forwarded on busy user to user 
C, if a Redirection number restriction parameter is present it is set to 
'Presentation allowed' in the encapsulated ANM contained in the 200 OK INVITE 
if ISUP/BICC- SIP-I interworking is applicable in Network A. 


Configuration 


Subscription options: 

• Connected user subscribed to COLR = ho 


SIP Parameter 


200 OK 


Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

ANM 

Redirection number restriction 
Presentation allowed 
or 
Redirection number restriction not present 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B), lAM ^ 
CFB is performed 

^ INVITE(Call-ID B-C) 

1 80 Ringing (Call-ID C-B, ACM) ^ 
^ 180 Ringing (Call-ID B-A) 

2flILQK INVITE (Call-ID C-B, ANM) ^ 
^ ACK (Call-ID B-C) 
^ 200 OK INVITE (Call-ID B-A) 

ACK (Call-ID A-B) ^ 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 

performs the diversion to a user in Network A 

Check: Is a 200 OK INVITE received at the interconnection interface? 

Check: Is an ANM encapsulated in the 200 OK? 

Check: Is the ISUP/BICC Redirection number restriction present set to 

'Presentation allowed' or is the parameter absent? 
Repeat this test in reverse direction. 
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Test case number 


SS cfb 016 


Test case group 


SIP-SIP/Service/GFB 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CFB performed in Network B, Notification of diverted-to user 
Redirecting number 'presentation allowed'. 

The user A and user G are in Network A. The user B is in the PSTN/PLIVIN part 
of Network B and is provided with GFB, Served user releases his/her number to 
diverted-to user = Release diverting number information. 
Ensure that when user A calls user B, the call is forwarded on busy user to user 
G, user G is notified of call diversion and informed of the diverting number. 
The notification information is present in the encapsulated lAM contained in the 
Redirecting number 'presentation allowed' and Redirection information if 
ISUP/BIGG - SIP-I interworking is applicable in Network B. 


Configuration 


Subscription options: 

• Served user releases his/her number to diverted-to user = Release diverting 
number information 


SIP Parameter 


Gontent-Type: multipart/mixed;boundary=[any boundary name] 

--[any boundary name] 

Gontent-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

lAM 

Redirecting number 

Address presentation restricted indicator 

presentation allowed 
Address signal (Diverting user) 
Original called number 

Address presentation restricted indicator 

presentation allowed 
Address signal 
Redirection information 

Original Redirection Reason 

unknown 
Redirecting indicator 
Redirection counter 
Redirecting reason 

User Busy 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFB is performed 
^ ^^(Gall-ID B-G, lAM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 

performs the diversion to a user in Network A 

Check: Is a INVITE request received at the interconnection interface? 

Check: Is an lAM encapsulated in the INVITE? 

Check: Is the Redirecting number present and the Address presentation 

restricted indicator is set to 'presentation allowed'? 
Check: Is the Original called number present and the Address presentation 

restricted indicator is set to 'presentation allowed'? 
Check: Is the Redirection number present? 
Check: Is Redirection information present and the Redirecting reason is set to 

'User Busy'? 
Repeat this test in reverse direction. 
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Test case number 


SS cfb 017 


Test case group 


SIP-SIP/Service/GFB 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CFB performed in Network B, Notification of diverted-to user 
Redirecting number 'presentation restricted'. 

The user A and user G are in Network A. The user B is in the PSTN/PLIVIN part 
of Network B and is provided with GFB, Served user releases his/her number to 
diverted-to user = Release diverting number information. 
Ensure that when user A calls user B, the call is forwarded on busy user to user 
G, user G is notified of call diversion and informed of the diverting number. 
The notification information is present in the encapsulated lAM contained in the 
Redirecting number 'presentation restricted' and Redirection information if 
ISUP/BIGG - SIP-I interworking is applicable in Network B. 


Configuration 


Subscription options: 

• Served user releases his/her number to diverted-to user = Do not release 
diverting numberinformation 


SIP Parameter 


Gontent-Type: multipart/mixed;boundary=[any boundary name] 

--[any boundary name] 

Gontent-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

lAM 

Redirecting number 

Address presentation restricted indicator 

presentation restricted 
Address signal (Diverting user) 
Original called number 

Address presentation restricted indicator 

presentation restricted 
Address signal 
Redirection information 

Original Redirection Reason 

unknown 
Redirecting indicator 
Redirection counter 
Redirecting reason 

User Busy 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFB is performed 
^ ^^(Gall-ID B-G, lAM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 

performs the diversion to a user in Network A 

Check: Is a INVITE request received at the interconnection interface? 

Check: Is an lAM encapsulated in the INVITE? 

Check: Is the Redirecting number present and the Address presentation 

restricted indicator is set to 'presentation restricted'? 
Check: Is the Original called number present and the Address presentation 

restricted indicator is set to 'presentation restricted'? 
Check: Is the Redirection number present? 
Check: Is Redirection information present and the Redirecting reason is set to 

'User Busy'? 
Repeat this test in reverse direction. 



ETSI 



121 



ETSI TS 101 585 VI .1.2 (2012-09) 



7.1.5.6.3 



Communication Forwarding No Reply (CFNR) 



Test case number 


SS cfnr 001 


Test case group 


SIP-SIP/Service/CFNR 


Reference 


4.5.2.6/f9] 


SELECTION EXPRESSION 


SE27 


Test purpose 


Communication forwarding no reply, basic rules. 

The user A and user C are in Network A. The user B is in network B and is 
provided with CFNR. 

Ensure that when user A calls user B, the call is forwarded no reply to user C. In 
the active call state, ensure the property of speech. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
^ 180Ringing(Call-IDB-A) 

CFB is performed 
^ INVITE(Call-ID B-C) 

180Ringing(Call-IDC-B) ^ 
^ 180Ringing(Call-IDB-A) 

200 OK INVITE(Call-ID C-B) ^ 
^ ACK(Call-ID B-C) 
^ 200 OK INVITE(Call-ID B-A) 

ACK(Call-IDA-B) ^ 
Communication 
Apply post test routine 


Comments 


Check: CDIV no reply is successful. 

Check: In the active call state, ensure the property of speech. 

Check: Is the P-Asserted-ldentity present set to the identity of the originating 

user? 
Repeat this test in reverse direction. 



Test case number 


SS cfnr 002 


Test case group 


SIP-SIP/Service/CFNR 


Reference 


4.5.2.6/f91 


SELECTION EXPRESSION 


SE27ANDSE30 


Test purpose 


Communication forwarding no reply, no notification. 

The user A and user C are in Network A. The user B is in network B and is 
provided with CFNR, subscription option: Originating user receives notification 
that his communication has been diverted = No. 

Ensure that when user A calls user B, the call is forwarded no reply to user C, 
originating user is not notified. 


Configuration 


Subscription options: 

• Originating user receives notification that his communication has been 
diverted = No 


SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
^ 180Ringing(Call-IDB-A) 

CFB is performed 
^ INVITE(Call-ID B-C) 

180Ringing(Call-IDC-B) ^ 
^ 180Ringing(Call-IDB-A) 
Apply post test routine 


Comments 


Check: No notification regarding call forwarding in network B is received at the 

interconnection interface. 
Repeat this test in reverse direction. 
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Test case number 


SS cfnr 003 


Test case group 


SIP-SIP/Service/CFNR 


Reference 


4.5.2.6/f91 


SELECTION EXPRESSION 


SE27ANDSE30 


Test purpose 


Communication forwarding no reply, originating user is notified. URI from 
the served user not received. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFNR Originating user receives notification that his 
communication has been diverted = Yes ("Served user allows the presentation of 
forwarded to URI to originating user in diversion notification" = No and. "Served 
user allows the presentation of his/her URI to originating user in diversion 
notification" = No. 

Ensure that when user A calls user B, the call is forwarded no reply to user 0, 
user A is notified of call diversion and not informed of the diverted-to number and 
served user number. 


Configuration 


Subscription options: 


• 
• 
• 


Originating user receives notification that his communication has been 

diverted = Yes 

Served user allows the presentation of forwarded to URI to originating user 

n diversion notification = No 

Served user allows the presentation of his/her URI to originating user in 

diversion notification = No 


SIP Parameter 


Igl Being Forwarded 


<sip:userB@networkB?Privacy=history>;index=1, 

<sip: userG@networkA;cause=408?Privacy=history>;index=1 .1 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
^ 180Ringing(Call-IDB-A) 

CFB is performed 
^ INVITE(Call-ID B-C) 
^ lL81 Being Forwarded(Call-ID B-A) 

180 Ringing(Call-ID C-B) ^ 
^ 180Ringing(Call-IDB-A) 
Apply post test routine 


Comments 


Check: A 181 Being Forwarded and a History-Info header is received at the 
interconnection interface in both entries in the History-Info header a 
Privacy header is escaped value 'history'. 

Check: Is the cause parameter in the last entry is set to '408'? 

NOTE: The history entries can be accumulated in "one" History-Info header or 
each history entry is present in one single History-Info header. 

Repeat this test in reverse direction. 
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Test case number 


SS cfnr 004 


Test case group 


SIP-SIP/Service/CFNR 


Reference 


4.5.2.6/f91 


SELECTION EXPRESSION 


SE27ANDSE30 


Test purpose 


Communication forwarding no reply, originating user is notified. URI from 
the diverted-to user received. 

The user A and user C are in network A. The user B is in network B and is 

provided with CFNR Originating user receives notification that his 

communication has been diverted = Yes and "Served user allows the 

presentation of forwarded to URI to originating user in diversion notification" 

=Yes. 

Ensure that when user A calls user B, the call is forwarded no reply to user 0, 

user A is notified of call diversion and informed of the diverted-to number. 


Configuration 


Subscription options: 


• 
• 


Originating user receives notification that his communication has been 
diverted = Yes 

Served user allows the presentation of forwarded to URI to originating user 
n diversion notification =Yes 


SIP Parameter 


181 Being Forwarded 


<sip:userB@networkB>;index=1 , 

<sip: userG@networkA;cause=408>;index=1 .1 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
^ 180Ringing(Call-IDB-A) 

CFB is performed 
^ INVITE(Call-ID B-C) 
^ 181 Being Forwarded(Call-ID B-A) 

180Ringing(Call-IDC-B) ^ 
^ 180Ringing(Call-IDB-A) 
Apply post test routine 


Comments 


Check: A 181 Being Forwarded is received at the interconnection interface. 
Check: A History-Info header is contained in the 181 with the URI of the 

diverted-to user. 
Check: Is the cause parameter in the last entry is set to '408'? 
NOTE: The history entries can be accumulated in "one" History-Info header or 

each history entry is present in one single History-Info header. 
Repeat this test in reverse direction. 
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Test case number 


SS cfnr 005 


Test case group 


SIP-SIP/Service/CFNR 


Reference 


4.5.2.6/f91 


SELECTION EXPRESSION 


SE27ANDSE30 


Test purpose 


Communication forwarding no reply, diverted-to user does not receive the 
URI of the served user. 

The user A and user C are in network A. The user B is in network B and is 
provided with "Served user allows the presentation of his/her URI to the diverted- 
to user" = No. 

Ensure that when user A calls user B, the call is forwarded no reply to user C, 
user C is not informed of the forwarding number. 


Configuration 


Subscription options: 

• Served user allows the presentation of his/her URI to the diverted-to user = 
No 


SIP Parameter 


INVITE 

Request line contains ';cause=408' 

History-Info header: 

<sip:userB@networkB?Privacy=history>;index=1, 
<sip: userC@network1 ;cause=408>;index=1 .1 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
^ 180Ringing(Call-IDB-A) 

CFB is performed 
^ INVITE(Call-ID B-C) 
Apply post test routine 


Comments 


Check: A History-Info header is received in the INVITE contains the URI of 
user B (served user) at the interconnection interface and a Privacy 
header is escaped set to 'history'. 

Check: Is the 'cause' parameter present in the Request line sent to user C 
(diverted-to user) set to '408'? 

Check: Is the cause parameter in the last entry is set to '408'? 

NOTE: The history entries can be accumulated in "one" History-Info header or 
each history entry is present in one single History-Info header. 

Repeat this test in reverse direction. 



Test case number 


SS cfnr 006 


Test case group 


SIP-SIP/Service/CFNR 


Reference 


4.5.2.6/[91 


SELECTION EXPRESSION 


SE27ANDSE30 


Test purpose 


Communication forwarding no reply, diverted-to user receives the URI of 
the diverted-to user. 

The user A and user C are in network A. The user B is in network B and is 
provided with "Served user allows the presentation of his/her URI to the diverted- 
to user" = Yes. 

Ensure that when user A calls user B, the call is forwarded no reply to user C, 
user C is informed of the forwarding number. 


Configuration 


Subscription options: 


• Served user allows the presentation of his/her URI to the diverted-to user = 
Yes 


SIP Parameter 


INVITE 

Request line contains ';cause=408' 

History-Info header: 

<sip:userB@networkB>;index=f, 

<sip: userC@network1 ;cause=408>;index=1 .1 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
^ 180Ringing(Call-IDB-A) 

CFB is performed 
^ INVITE(Call-ID B-C) 
Apply post test routine 


Comments 
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Test case number 


SS cfnr 007 


Test case group 


SIP-SIP/Service/CFNR 


Reference 


4.5.2.6/f91 


SELECTION EXPRESSION 


SE27ANDSE30 


Test purpose 


Communication forwarding no reply, full notification. 

The user A and user C are in network A. Tine user B is in network B and is 
provided with CFNR Originating user receives notification that his 
communication has been diverted = Yes, ("Served user allows the presentation 
of forwarded to URI to originating user in diversion notification" = Yes, "diverting 
number is released to the diverted-to user" = Yes. 

Ensure that when user A calls user B, the call is forwarded no reply to user C, 
user A is notified of call diversion and informed of the diverted-to number and 
user C is informed of the forwarding number. 


Configuration 


Subscription options: 


• 
• 

• 


unginating user receives notiTication that his communication nas Deen 

diverted = Yes 

Served user allows the presentation of forwarded to URI to originating user 

in diversion notification = Yes 

diverting number is released to the diverted-to user = Yes 


SIP Parameter 


INVITE: 1 


Req 
Hist( 

< 
< 


uest line contains ';cause=408' 
Dry-info header: 


:sip:userB@networkB&Reason=SIP;cause=408>;index=t, 


:sip: userC@networkA;cause=486>;index=1 .1 


^^feeina Forwarded 


History-Info header: 


<sip:userB@network>;index=1 , 

<sip: userC@networkA;cause=408>;index=1 .f 


poo OK INVITE 


History-Info header: 

<sip:userB@networkB>;index=1 , 

<sip: userC@networkA;cause=408>;index=1 .1 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
^ 180Ringing(Call-IDB-A) 

CFB is performed 
^ INVITE(Gall-ID B-C) 
^ pi Being Forwarded(Call-ID B-A 

180 Ringing(Call-ID C-B) ^ 
^ 180Ringing(Call-IDB-A) 

200 OK INVITE(Call-ID C-B) ^ 
^ ACK(Call-ID C-B) 
^ 200 OK INVITE(Call-ID B-A) 

ACK(Call-IDA-B) ^ 
Apply post test routine 


Comments 


Check: A History-Info header is received in the INVITE at the interconnection 

interface sent to user C containing the URI identifying the served user. 
Check: A History-Info header is received in the 181 Being Forwarded at the 

interconnection interface sent to user A containing the URI identifying 

the diverted-to user. 
Check: Is the 'cause' parameter present in the Request line sent to user C 

(diverted-to user) set to '408'? 
Check: Is the cause parameter in the last entry is set to '408'? 
NOTE: The history entries can be accumulated in "one" History-Info header or 

each history entry is present in one single History-Info header. 
Repeat this test in reverse direction. 
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Test case number 


SS cfnr 008 


Test case group 


SIP-SIP/Service/CFNR 


Reference 


4.5.2.6/f9] 


SELECTION EXPRESSION 


SE27 


Test purpose 


Communication forwarding no reply, unsuccessful UDUB. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFNR. 

Ensure that when user A calls user B, the call is forwarded no reply to user C 
and user C is user determined user busy. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
^ 180Ringing(Call-IDB-A) 
CFB is performecJ 

^ INVITE(Call-ID B-C) 

486 Busy Here(Call-ID C-B) ^ 
^ ACK(Call-ID B-C) 
^ 486 Busy Here(Call-ID A-B) 

ACK(Call-IDA-B) ^ 


Comments 


Check: The dialogue is terminated by receiving a 486 Busy Here. 
Repeat this test in reverse direction. 



Test case number 


SS cfnr 009 


Test case group 


SIP-SIP/Service/CFNR 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE27 


Test purpose 


Communication forwarding no reply, unsuccessful NDUB. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFNR. 

Ensure that when user A calls user B, the call is forwarded no reply to user C 
and user C is network determined user busy. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
^ 180Ringing(Call-IDB-A) 
CFB is performed 

^ INVITE(Call-ID B-C) 

486 Busy Here(Call-ID C-B) ^ 
^ ACK(Call-ID B-C) 
^ 486 Busy Here(Call-ID A-B) 

ACK(Call-IDA-B) ^ 


Comments 


Check: The dialogue is terminated by receiving a 486 Busy Here. 
Repeat this test in reverse direction. 
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Test case number 


SS cfnr 010 


Test case group 


SIP-SIP/Service/CFNR 


Reference 


4.5.2.6/f91 


SELECTION EXPRESSION 


SE 27 AND SE 30 AND [Network A] is SE 9 


Test purpose 


Communication forwarding no reply, interaction with a not trusted 
network. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFNR Originating user receives notification that his 
communication has been diverted = Yes ("Served user allows the presentation of 
forwarded to URI to originating user in diversion notification"=Yes, "diverting 
number is released to the diverted-to user"=Yes. 

Ensure that when user A calls user B, the call is forwarded no reply to user 0, 
user A is notified of call diversion and not informed of the diverted-to number and 
user is not informed of the forwarding number. 


Configuration 


Subscription options: 


• 
• 
• 

• 


Originating user receives notification that his communication has been 

diverted = Yes 

Served user allows the presentation of forwarded to URI to originating us J 

in diversion notification = No 

Served user allows the presentation of his/her URI to originating user in 

diversion notification = No 

Served user allows the presentation of his/her URI to the diverted-to user = 


No 


SIP Parameter 


INVITE: no History-Info header 


181 Being Forwarded no History-Info header 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
^ 180Ringing(Call-IDB-A) 

CFB is performed 
^ INVITE(Call-ID B-C) 
^ T81 Being Forwarded(Call-ID B-A) 
Apply post test routine 


Comments 


Check: No History-Info header is received in the INVITE at the interconnection 

interface. 
Check: No History-Info header is received in the 181 Being Forwarded at the 

interconnection interface (if sent). 
Repeat this test in reverse direction. 
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Test case number 


SS cfnr 011 


Test case group 


SIP-SIP/Service/CFNR 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B] SE 17 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CFNR performed in Network B, Notification subscription 
options is set to presentation not allowed. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 

of Network B and is provided with CFNR, Calling user receives notification that 

his call has been diverted (forwarded or deflected) = yes, without diverted-to 

user number. 

Ensure that when user A calls user B, the call is forwarded on no reply to user C, 

user A is not notified about call diversion. 

The notification information is present in the encapsulated CPG contained in the 

Redirection number and Call diversion information if SIP-I - ISUP/BICC 

interworking is applicable in Network B. 


Configuration 


Subscription options: 


• Calling user receives notification that his call has been diverted (forwarde(i 
or deflected) = no 


SIP Parameter 


183 Session Progress 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

CPG 

Event indicator 

Alerting or Progress 
Redirection number 

Address signal (Diverted-to user) 
Call diversion information 

Notification subscription options 
presentation not allowed 

Redirecting reason 
No reply 
Generic notification 

call is diverting 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
^ 1 80 Ringing (Call-ID B-A, ACM) 

CFNR is performed 
^ INVITE(Call-ID B-C, lAM) 
^ 1 83 Session Progress (Call-ID B-A, CPG) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 

performs the diversion to a user in Network A 

Check: Is a 183 Session Progress received at the interconnection interface? 

Check: Is an CPG encapsulated in the 1 83? 

Check: Is the Called party's status indicator set to 'no indication'? 

Check: Is the Redirection number present? 

Check: Is Notification subscription options indicator set to 'presentation not 

allowed'? 
Check: Is the Redirecting reason set to 'No reply'? 
Repeat this test in reverse direction. 
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Test case number 


SS cfnr 012 


Test case group 


SIP-SIP/Service/CFNR 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B] SE 17 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CFNR performed in Network B, Notification subscription 
options is set to presentation allowed without redirection number. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CFNR, Calling user receives notification that 
his call has been diverted (forwarded or deflected) = yes, without diverted-to 
user number. 

Ensure that when user A calls user B, the call is forwarded on no reply to user C, 
user A is notified of call diversion and informed of the diverted-to number. 
The notification information is present in the encapsulated CPG contained in the 
Redirection number and Call diversion information if SIP-I - ISUP/BICC 
interworking is applicable in Network B. 


Configuration 


Subscription options: 


• Calling user receives notification that his call has been diverted (forwarde(i 
or deflected) = yes, without diverted-to user number 


SIP Parameter 


183 Session Progress 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

CPG 

Event indicator 

Alerting or Progress 
Redirection number 

Address signal (Diverted-to user) 
Call diversion information 

Notification subscription options 

presentation allowed without redirection number 

Redirecting reason 
No reply 
Generic notification 

call is diverting 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
^ 1 80 Ringing (Call-ID B-A, ACM) 

CFNR is performed 
^ INVITE(Call-ID B-C, lAM) 
^ '1 83 Session Progress (Call-ID B-A, ACM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 

performs the diversion to a user in Network A 

Check: 183 Session Progress is received at the interconnection interface. 

Check: Is an CPG encapsulated in the 1 83? 

Check: is the Called party's status indicator set to 'no indication'? 

Check: Is the Redirection number present? 

Check: Is Notification subscription options indicator is set to 'presentation 

allowed without redirection number'? 
Check: Is the Redirecting reason set to 'No reply'? 
Repeat this test in reverse direction. 
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Test case number 


SS cfnr 013 


Test case group 


SIP-SIP/Service/CFNR 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B] SE 17 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CFNR performed in Network B, Notification subscription 
options is set to presentation allowed with redirection number. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 

of Network B and is provided with CFNR, Calling user receives notification that 

his call has been diverted (forwarded or deflected) = yes, with diverted-to user 

number. 

Ensure that when user A calls user B, the call is forwarded on no reply to user C, 

user A is notified of call diversion and informed of the diverted-to number. 

The notification information is present in the encapsulated CPG contained in the 

Redirection number and Call diversion information if SIP-I - ISUP/BICC 

interworking is applicable in Network B. 


Configuration 


Subscription options: 


• Calling user receives notification that his call has been diverted (forwarde(i 
or deflected) = yes, with diverted-to user number 


SIP Parameter 


183 Session Progress 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

CPG 

Event indicator 

Alerting or Progress 
Redirection number 

Address signal (Diverted-to user) 
Call diversion information 

Notification subscription options 

presentation allowed with redirection number 

Redirecting reason 
No reply 
Generic notification 

call is diverting 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
^ 1 80 Ringing (Call-ID B-A, ACM) 

CFNR is performed 
^ INVITE(Call-ID B-C, lAM) 
^ '1 83 Session Progress (Call-ID B-A, ACM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 

performs the diversion to a user in Network A 

Check: 183 Session Progress is received at the interconnection interface. 

Check: Is an CPG encapsulated in the 1 83? 

Check: Is the Called party's status indicator set to 'no indication'? 

Check: Is the Redirection number present? 

Check: Is Notification subscription options indicator is set to 'presentation 

allowed with redirection number'? 
Check: Is the Redirecting reason set to 'No reply'? 
Repeat this test in reverse direction. 
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Test case number 


SS cfnr 014 


Test case group 


SIP-SIP/Service/CFNR 


Reference 


6.7/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 53 


Test purpose 


SIP-I support. CFNR performed in Network B, Restriction of the Redirection 
number. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CFNR, Diverted-to user is subscribed to the 
COLR service in Permanent mode. 

Ensure that when user A calls user B, the call is forwarded on no reply to user C, 
a Redirection number restriction parameter is present set to 'Presentation 
restricted' in the encapsulated ANM contained in the 200 OK INVITE if 
ISUP/BICC- SIP-I interworking is applicable in Network A. 


Configuration 


Subscription options: 

• Connected user subscribed to COLR, Permanent = yes 


SIP Parameter 


200 OK 


Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

ANM 

Redirection number restriction 
Presentation restricted 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B), lAM ^ 
^ 1 80 Ringing (Call-ID B-A, ACM) 

CFNR is performed 
^ INVITE(Call-ID B-C) 

1 80 Ringing (Call-ID C-B, ACM) ^ 
^ 180 Ringing (Call-ID B-A) 

200 OK INVITE (Call-ID C-B, ANM) ^ 
^ ACK (Call-ID B-C) 
^ 200 OK INVITE (Call-ID B-A) 

ACK (Call-ID A-B) ^ 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 

performs the diversion to a user in Network A 

Check: Is a 200 OK INVITE received at the interconnection interface? 

Check: Is an ANM encapsulated in the 200 OK? 

Check: Is the ISUP/BICC Redirection number restriction set to 'Presentation 

restricted'? 
Repeat this test in reverse direction. 
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Test case number 


SS cfnr 015 


Test case group 


SIP-SIP/Service/CFNR 


Reference 


6.7/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 53 


Test purpose 


SIP-I support. CFNR performed in Network B, No restriction of the 
Redirection number. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CFNR, Diverted-to user is not subscribed to 
the COLR service. 

Ensure that when user A calls user B, the call is forwarded on no reply to user C, 
if a Redirection number restriction parameter is present it is set to 'Presentation 
allowed' in the encapsulated ANM contained in the 200 OK INVITE if 
ISUP/BICC- SIP-I interworking is applicable in Network A. 


Configuration 


Subscription options: 

• Connected user subscribed to COLR = no 


SIP Parameter 


200 OK 


Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

ANM 

Redirection number restriction 
Presentation allowed 
or 
Redirection number restriction not present 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B), lAM ^ 
^ 180 Ringing (Call-ID B-A) 

CFNR is performed 
^ INVITE(Call-ID B-C) 

1 80 Ringing (Call-ID C-B, ACM) ^ 
^ 180 Ringing (Call-ID B-A) 

200 OK INVITE (Call-ID C-B, ANM) ^ 
^ ACK (Call-ID B-C) 
^ 200 OK INVITE (Call-ID B-A) 

ACK (Call-ID A-B) ^ 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 

performs the diversion to a user in Network A 

Check: Is a 200 OK INVITE received at the interconnection interface? 

Check: Is an ANM encapsulated in the 200 OK? 

Check: Is the ISUP/BICC Redirection number restriction present set to 

'Presentation allowed' or is the parameter absent? 
Repeat this test in reverse direction. 
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Test case number 


SS cfnr 016 


Test case group 


SIP-SIP/Service/CFNR 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


[Network B] SE 17 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CFNR performed in Network B, Notification of diverted-to 
user Redirecting number 'presentation allowed'. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 

of Network B and is provided with CFNR, Served user releases his/her number 

to diverted-to user = Release diverting number information. 

Ensure that when user A calls user B, the call is forwarded on no reply to user C, 

user C is notified of call diversion and informed of the diverting number. 

The notification information is present in the encapsulated lAM contained in the 

Redirecting number 'presentation allowed' and Redirection information if 

ISUP/BICC - SIP-I interworking is applicable in Network B. 


Configuration 


Subscription options: 

• Served user releases his/her number to diverted-to user = Release diverting 
number information 


SIP Parameter 


Content-Type: multipart/mixed;boundary=[any boundary name] 

--[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

lAM 

Redirecting number 

Address presentation restricted indicator 

presentation allowed 
Address signal (Diverting user) 
Original called number 

Address presentation restricted indicator 

presentation allowed 
Address signal 
Redirection information 

Original Redirection Reason 

unknown 
Redirecting indicator 
Redirection counter 
Redirecting reason 

No reply 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
^ 1 80 Ringing (Call-ID B-A, ACM) 

CFNR is performed 
^ PPff (Call-ID B-C, lAM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 

performs the diversion to a user in Network A 

Check: Is a INVITE request received at the interconnection interface? 

Check: Is an lAM encapsulated in the INVITE? 

Check: Is the Redirecting number present and the Address presentation 

restricted indicator is set to 'presentation allowed'? 
Check: Is the Original called number present and the Address presentation 

restricted indicator is set to 'presentation allowed'? 
Check: Is the Redirection number present? 
Check: Is Redirection information present and the Redirecting reason is set to 

'No reply'? 
Repeat this test in reverse direction. 
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Test case number 


SS cfnr 017 


Test case group 


SIP-SIP/Service/CFNR 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CFNR performed in Network B, Notification of diverted-to 
user Redirecting number 'presentation restricted'. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 

of Network B and is provided with CFNR, Served user releases his/her number 

to diverted-to user = Release diverting number information. 

Ensure that when user A calls user B, the call is forwarded on no reply to user C, 

user C is notified of call diversion and informed of the diverting number. 

The notification information is present in the encapsulated lAM contained in the 

Redirecting number 'presentation restricted' and Redirection information if 

ISUP/BICC - SIP-I interworking is applicable in Network B. 


Configuration 


Subscription options: 

• Served user releases his/her number to diverted-to user = Do not release 
diverting numberinformation 


SIP Parameter 


Content-Type: multipart/mixed;boundary=[any boundary name] 

--[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

lAM 

Redirecting number 

Address presentation restricted indicator 

presentation restricted 
Address signal (Diverting user) 
Original called number 

Address presentation restricted indicator 

presentation restricted 
Address signal 
Redirection information 

Original Redirection Reason 

unknown 
Redirecting indicator 
Redirection counter 
Redirecting reason 

No reply 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
^ 1 80 Ringing (Call-ID B-A, ACM) 

CFNR is performed 
^ PPff (Call-ID B-C, lAM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 

performs the diversion to a user in Network A 

Check: Is a INVITE request received at the interconnection interface? 

Check: Is an lAM encapsulated in the INVITE? 

Check: Is the Redirecting number present and the Address presentation 

restricted indicator is set to 'presentation restricted'? 
Check: Is the Original called number present and the Address presentation 

restricted indicator is set to 'presentation restricted'? 
Check: Is the Redirection number present? 
Check: Is Redirection information present and the Redirecting reason is set to 

'No reply'? 
Repeat this test in reverse direction. 
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7.1.5.6.4 



Communication Forwarding Not Logged in (CFNL) 



Test case number 


SS cfnl 001 


Test case group 


SIP-SIP/Service/CFNL 


Reference 


4.5.2.6/f91 


SELECTION EXPRESSION 


SE28 


Test purpose 


Communication forwarding not logged in, basic rules. 

The user A and user C are in Network A. The user B is in network B and is 
provided with CFNL. 

Ensure that when user A calls user B, the call is forwarded not logged in to user 
C. In the active call state, ensure the property of speech. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFNL is performed 
^ INVITE(Call-ID B-C) 

180Ringing(Call-IDC-B) ^ 
^ 180Ringing(Call-IDB-A) 

200 OK INVITE(Call-ID C-B) ^ 
^ ACK(Call-ID B-C) 
^ 200 OK INVITE(Call-ID B-A) 

ACK(Call-ID A-B) ^ 
Communication 
Apply post test routine 


Comments 


Check: The CDIV not logged in is successful. 

Check: In the active call state, ensure the property of speech. 

Check: Is the P-Asserted-ldentity present set to the identity of the originating 

user? 
Repeat this test in reverse direction. 



Test case number 


SS cfnl 002 


Test case group 


SIP-SIP/Service/CFNL 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE 28 AND SE 30 


Test purpose 


Communication forwarding not logged in, no notification. 

The user A and user C are in Network A. The user B is in network B and is 
provided with CFNL, subscription option: Originating user receives notification 
that his communication has been diverted = No. 

Ensure that when user A calls user B, the call is forwarded not logged in to user 
C, originating user is not notified. 


Configuration 


Subscription options: 

• Originating user receives notification that his communication has been 
diverted = No 


SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFNL is performed 
^ INVITE(Call-ID B-C) 

180Ringing(Call-IDC-B) ^ 
^ 180Ringing(Call-IDB-A) 
Apply post test routine 


Comments 


Check: No notification regarding call forwarding in network B is received at 

interconnection interface. 
Repeat this test in reverse direction. 
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Test case number 


SS cfnl 003 


Test case group 


SIP-SIP/Service/CFNL 


Reference 


4.5.2.6/f91 


SELECTION EXPRESSION 


SE 28 AND SE 30 


Test purpose 


Communication forwarding not logged in, originating user is notified. URI 
of the diverted-to user not received. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFNL Originating user receives notification that his communication 
has been diverted = Yes and ("Served user allows the presentation of forwarded 
to URI to originating user in diversion notification" = No and. "Served user allows 
the presentation of his/her URI to originating user in diversion notification" = No. 
Ensure that when user A calls user B, the call is forwarded not logged in to user 
0, user A is notified of call diversion and not informed of the diverted-to number 
and the served user number. 


Configuration 


Subscription options: 


• 
• 
• 


Originating user receives notification that his communication has been 

diverted = Yes 

Served user allows the presentation of forwarded to URI to originating use| 

in diversion notification = No 

Served user allows the presentation of his/her URI to originating user in 

diversion notification = No 


SIP Parameter 


^81 Being Forwarded 


<sip:userB@networkB ?Privacy=history>;index= 1 , 

<sip: userC@networkA;cause=404 ?Privacy=history>;inclex= 1 . 1 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFNL is performed 

^ INVITE(Call-ID B-C) 

^ iatPeing Forwarded(Call-ID B-A) 

180Ringing(Call-IDC-B) ^ 
^ 180Ringing(Call-IDB-A) 
Apply post test routine 


Comments 


Check: A 181 Being Forwarded and a History-Info header is received at 

theinterconnection interface in both entries in the History-Info header a 
Privacy header is escaped value 'history'. 

Check: is the cause parameter in the last entry is set to '404'? 

NOTE: The history entries can be accumulated in "one" History-Info header or 
each history entry is present in one single History-Info header. 

Repeat this test in reverse direction. 



ETSI 



137 



ETSI TS 101 585 VI .1.2 (2012-09) 



Test case number 


SS cfnl 004 


Test case group 


SIP-SIP/Service/CFNL 


Reference 


4.5.2.6/f91 


SELECTION EXPRESSION 


SE 28 AND SE 30 


Test purpose 


Communication forwarding not logged in, originating user is notified. URI 
from the diverted-to user received. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFNL Originating user receives notification that his communication 
has been diverted = Yes and ("Served user allows the presentation of forwarded 
to URI to originating user in diversion notification" = Yes. 
Ensure that when user A calls user B, the call is forwarded not logged in to user 
0, user A is notified of call diversion and informed of the diverted-to number. 


Configuration 


Subscription options: 


• 

• 


Originating user receives notification that his communication has been 
diverted = Yes 

Served user allows the presentation of forwarded to URI to originating usq| 
n diversion notification = Yes 


SIP Parameter 


,181 Being Forwarded 


<sip:userB@networkB>;inclex= 1 , 


<sip: userG(g)networkA;cause=4cJ?>7HBB5?W 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFNL is performed 

^ INVITE(Call-ID B-C) 

^ l81 Being Forwarded(Call-ID B-A) 

180Ringing(Call-IDC-B) ^ 
^ 180Ringing(Call-IDB-A) 
Apply post test routine 


Comments 


Check: A 181 Being Forwarded is received at interconnection interface. 
Check: A History-Info header is contained in the 181 with the URI of the 

served user and the URI of the diverted-to user. 
Check: Is the cause parameter in the last entry is set to '404'? 
NOTE: The history entries can be accumulated in "one" History-Info header or 

each history entry is present in one single History-Info header. 
Repeat this test in reverse direction. 
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Test case number 


SS cfnl 005 


Test case group 


SIP-SIP/Service/CFNL 


Reference 


4.5.2.6/f91 


SELECTION EXPRESSION 


SE 28 AND SE 30 


Test purpose 


Communication forwarding not logged in, diverted-to user does not 
receive the URI of the diverted-to user. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFNL "Served user allows the presentation of his/her URI to 
diverted-to user" = No. 

Ensure that when user A calls user B, the call is forwarded not logged in to user 
0, user is not informed of the forwarding number. 


Configuration 


Subscription options: 

• Served user allows the presentation of his/her URI to diverted-to user = No 


SIP Parameter 


INVITE 

Request line contains ';cause=404' 

History-Info header: 

<sip:userB@networkB?Privacy=history>;index=1, 
<sip: userG@network1 ;cause=404>;index=1 .1 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFNL is performed 
^ INVITE(Call-ID B-C) 
Apply post test routine 


Comments 


Check: A History-Info header is received in the INVITE contains the URI of 
user B (served user) at the interconnection interface and a Privacy 
header is escaped set to 'history'. 

Check: Is the 'cause' parameter present in the Request line sent to user C 
(diverted-to user) set to '404'? 

Check: Is the cause parameter in the last entry is set to '404'? 

NOTE: The history entries can be accumulated in "one" History-Info header or 
each history entry is present in one single History-Info header. 

Repeat this test in reverse direction. 
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Test case number 


SS cfnl 006 


Test case group 


SIP-SIP/Service/CFNL 


Reference 


4.5.2.6/f91 


SELECTION EXPRESSION 


SE 28 AND SE 30 


Test purpose 


Communication forwarding not logged in, diverted-to user receives the URI 
of the served user. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFNL "Served user allows the presentation of his/her URI to 
diverted-to user" = Yes. 

Ensure that when user A calls user B, the call is forwarded not logged in to user 
0, user is informed of the forwarding number. 


Configuration 


Subscription options: 

• Served user allows the presentation of his/her URI to diverted-to user = ^W 


SIP Parameter 


INVITE 

Request line contains ';cause=404' 

History-Info header: 

<sip:userB@networkB>;index= 1, 

<sip: userC@networkA;cause=404>;index=1 .1 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFNL is performed 
^ INVITE(Call-ID B-C) 
Apply post test routine 


Comments 


Check: A History-Info header is received in the INVITE contains the URI of 
user B (served user) at the interconnection interface. 

Check: Is the 'cause' parameter present in the Request line sent to user C 
(diverted-to user) set to '404'? 

Check: Is the cause parameter in the last entry is set to '404'? 

NOTE: The history entries can be accumulated in "one" History-Info header or 
each history entry is present in one single History-Info header. 

Repeat this test in reverse direction. 
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Test case number 


SS cfnl 007 


Test case group 


SIP-SIP/Service/GFNL 


Reference 


4.5.2.6/f91 


SELECTION EXPRESSION 


SE 28 AND SE 30 


Test purpose 


Communication forwarding not logged in, full notification. 

The user A and user G are in network A. The user B is in network B and is 
provided with GFNL Originating user receives notification that his communication 
has been diverted = Yes, ("Served user allows the presentation of forwarded to 
URI to originating user in diversion notification" =Yes, "diverting number is 
released to the diverted-to user" =Yes. 

Ensure that when user A calls user B, the call is forwarded not logged in to user 
G, user A is notified of call diversion and informed of the diverted-to number and 
user G is informed of the forwarding number. 


Configuration 


Subscription options: 


• unginating user receives notiTication mat nis communicaTion has been 
diverted = Yes 

• Served user allows the presentation of forwarded to URI to originating user 
in diversion notification = Yes 

• diverting number is released to the diverted-to user = Yes 


SIP Parameter 


INVITE: 

Request line contains ';cause=404' 

History-Info header: 

<sip:userB@networkB&Reason=SIP;cause=404>;index=t, 
<sip: userG@networkA;cause=404>;index=1 .1 

^^^eing Forwarded 

History-Info header: 

<sip:userB@network>;index=1 , 

<sip: userG@networkA;cause=404>;index=1 .f 

poo OK INVITE 

History-Info header: 

<sip:userB@networkB>;index=1 , 

<sip: userG@networkA;cause=404>;index=1 .1 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFNL is performed 

^ INVITE(Call-ID B-G) 

180Ringing(Call-IDC-B) ^ 
^ 180Ringing(Gall-IDB-A) 

200 OK INVITE(Gall-ID G-B) ^ 
^ AGK(Gall-ID G-B) 
^ 200 OK INVITE(Gall-ID B-A) 

AGK(Gall-IDA-B) ^ 
Apply post test routine 


Comments 


Check: A History-Info header is received in the INVITE at the interconnection 

interface sent to user G containing the URI identifying the served user. 
Check: A History-Info header is received in the 181 Being Forwarded at the 

interconnection interface sent to user A containing the URI identifying 

the diverted-to user. 
Check: Is the 'cause' parameter present in the Request line sent to user G 

(diverted-to user) set to '404'? 
Check: Is the cause parameter in the last entry is set to '404'? 
NOTE: The history entries can be accumulated in "one" History-Info header or 

each history entry is present in one single History-Info header. 
Repeat this test in reverse direction. 
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Test case number 


SS cfnl 008 


Test case group 


SIP-SIP/Service/CFNL 


Reference 


4.5.2.6/f9] 


SELECTION EXPRESSION 


SE28 


Test purpose 


Communication forwarding not logged in, unsuccessful UDUB. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFNL. 

Ensure that when user A calls user B, the call is forwarded not logged in to user 
and user is user determined user busy. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFNL is performed 

486 Busy Here(Call-ID C-B) ^ 
^ ACK(Call-ID B-C) 
^ 486 Busy Here(Call-ID A-B) 

ACK(Call-IDA-B) ^ 


Comments 


Check: The dialogue is terminated by receiving a 486 Busy Here. 
Repeat this test in reverse direction. 



Test case number 


SS cfnl 009 


Test case group 


4.5.2.6/[9] 


Reference 


ES 183 004 


SELECTION EXPRESSION 


SE28 


Test purpose 


Communication forwarding not logged in, unsuccessful NDUB. 

The user A and user G are in network A. The user B is in network B and is 
provided with GFNL. 

Ensure that when user A calls user B, the call is forwarded not logged in to user 
G and user G is busy. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFNL is performed 

486 Busy Here(Call-ID C-B) ^ 
^ AGK(Gall-ID B-G) 
^ 486 Busy Here(Gall-ID A-B) 

AGK(Gall-ID A-B) ^ 


Comments 


Check: The dialogue is terminated by receiving a 486 Busy Here. 
Repeat this test in reverse direction. 
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Test case number 


SS cfnl 010 


Test case group 


SIP-SIP/Service/CFNL 


Reference 


4.5.2.6/f9] 


SELECTION EXPRESSION 


SE 28 AND SE 30 AND [Network A] SE 9 


Test purpose 


Communication forwarding not logged in, interaction with a not trusted 
network. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFNL Originating user receives notification that his communication 
has been diverted = Yes ("Served user allows the presentation of forwarded to 
URI to originating user in diversion notification"=Yes, "diverting number is 
released to the diverted-to user"=Yes. 

Ensure that when user A calls user B, the call is forwarded not logged in to user 
0, user A is notified of call diversion and not informed of the diverted-to number 
and user is not informed of the forwarding number. 


Configuration 


Subscription options: 


• 
• 
• 

• 


Originating user receives notification that his communication has been 

diverted = Yes 

Served user allows the presentation of forwarded to URI to originating us J 

in diversion notification = No 

Served user allows the presentation of his/her URI to originating user in 

diversion notification = No 

Served user allows the presentation of his/her URI to the diverted-to user = 


No 


SIP Parameter 


INVITE: no History-Info header 


181 Being Forwarded no History-Info header 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFNL is performed 
^ INVITE(Call-ID B-C) 
^ p1 Being Forwarded(Call-ID B-A) 
Apply post test routine 


Comments 


Check: No History-Info header is received in the INVITE at the interconnection 

interface. 
Check: No History-Info header is received in the 181 Being Forwarded at the 

interconnection interface (if sent). 
Repeat this test in reverse direction. 
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Test case number 


SS cfnl 011 


Test case group 


SIP-SIP/Service/CFNL 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CFNL performed in Network B, Notification subscription 
options is set to presentation not allowed. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 

of Network B and is provided with CFNL, Calling user receives notification that 

his call has been diverted (forwarded or deflected) = yes, without diverted-to 

user number. 

Ensure that when user A calls user B, the call is forwarded on Mobile subscriber 

not reachable to user C, user A is not notified about call diversion. 

The notification information is present in the encapsulated ACM contained in the 

Redirection number and Call diversion information if SIP-I - ISUP/BICC 

interworking is applicable in Network B. 


Configuration 


Subscription options: 


• Calling user receives notification that his call has been diverted (forwarde(i 
or deflected) = no 


SIP Parameter 


183 Session Progress 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

ACM 

Backward call indicator 

Called party's status indicator 
no indication 
Redirection number 

Address signal {Diverted-to user) 
Call diversion information 

Notification subscription options 

presentation not allowed 
Redirecting reason 

Mobile subscriber not reachable 
Generic notification 
call is diverting 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFNL is performed 

^ INVITE(Call-ID B-C, lAM) 
^ 1 83 Session Progress (Call-ID B-A, ACM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 

performs the diversion to a user in Network A 

Check: Is a 183 Session Progress received at the interconnection interface? 

Check: Is an ACM encapsulated in the 1 83? 

Check: Is the Called party's status indicator set to 'no indication'? 

Check: Is the Redirection number present? 

Check: Is Notification subscription options indicator set to 'presentation not 

allowed'? 
Check: Is the Redirecting reason set to 'Mobile subscriber not reachable'? 
Repeat this test in reverse direction. 
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Test case number 


88 cfnl 012 


Test case group 


8IP-8IP/8ervice/CFNL 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B] 8E 1 7 AND 8E 47 AND 8E 55 


Test purpose 


SIP-I support. CFNL performed in Network B, Notification subscription 
options is set to presentation allowed without redirection number. 

The user A and user C are in Network A. The user B is in the P8TN/PLMN part 

of Network B and is provided with CFNL, Calling user receives notification that 

his call has been diverted (forwarded or deflected) = yes, without diverted-to 

user number. 

Ensure that when user A calls user B, the call is forwarded on Mobile subscriber 

not reachable to user C, user A is notified of call diversion and informed of the 

diverted-to number. 

The notification information is present in the encapsulated ACM contained in the 

Redirection number and Call diversion information if 8IP-I - I8UP/BICC 

interworking is applicable in Network B. 


Configuration 


Subscription options: 

or deflected) = yes, without diverted-to user number 


SIP Parameter 


,183 Session Progress 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

ACM 

Backward call indicator 

Called party's status indicator 
no indication 
Redirection number 

Address signal (Diverted-to user) 
Call diversion information 

Notification subscription options 

presentation allowed without redirection number 
Redirecting reason 

Mobile subscriber not reachable 
Generic notification 
call is diverting 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFNL is performed 
^ INVITE(Call-ID B-C, lAM) 
^ 1 83 Session Progress (Call-ID B-A, ACM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 

performs the diversion to a user in Network A 

Check: 183 Session Progress is received at the interconnection interface. 

Check: Is an ACM encapsulated in the 1 83? 

Check: Is the Called party's status indicator set to 'no indication'? 

Check: Is the Redirection number present? 

Check: Is Notification subscription options indicator is set to 'presentation 

allowed without redirection number'? 
Check: Is the Redirecting reason set to 'Mobile subscriber not reachable'? 
Repeat this test in reverse direction. 
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Test case number 


88 cfnl 013 


Test case group 


8IP-8IP/8ervice/CFNL 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B] 8E 1 7 AND 8E 47 AND 8E 55 


Test purpose 


SIP-I support. CFNL performed in Network B, Notification subscription 
options is set to presentation allowed with redirection number. 

The user A and user C are in Network A. The user B is in the P8TN/PLMN part 

of Network B and is provided with CFNL, Calling user receives notification that 

his call has been diverted (forwarded or deflected) = yes, with diverted-to user 

number. 

Ensure that when user A calls user B, the call is forwarded on Mobile subscriber 

not reachable to user C, user A is notified of call diversion and informed of the 

diverted-to number. 

The notification information is present in the encapsulated ACM contained in the 

Redirection number and Call diversion information if 8IP-I - I8UP/BICC 

interworking is applicable in Network B. 


Configuration 


Subscription options: 

or deflected) = yes, with diverted-to user number 


SIP Parameter 


,183 Session Progress 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

ACM 

Backward call indicator 

Called party's status indicator 
no indication 
Redirection number 

Address signal (Diverted-to user) 
Call diversion information 

Notification subscription options 

presentation allowed with redirection number 
Redirecting reason 

Mobile subscriber not reachable 
Generic notification 
call is diverting 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFNL is performed 
^ INVITE(Call-ID B-C, lAM) 
^ 1 83 Session Progress (Call-ID B-A, ACM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 

performs the diversion to a user in Network A 

Check: 183 Session Progress is received at the interconnection interface 

Check: Is an ACM encapsulated in the 1 83? 

Check: Is the Called party's status indicator set to 'no indication'? 

Check: Is the Redirection number present? 

Check: Is Notification subscription options indicator is set to 'presentation 

allowed with redirection number'? 
Check: Is the Redirecting reason set to 'Mobile subscriber not reachable'? 
Repeat this test in reverse direction. 
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Test case number 


SS cfnl 014 


Test case group 


SIP-SIP/Service/CFNL 


Reference 


6.7/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 53 


Test purpose 


SIP-I support. CFNL performed in Network B, Restriction of the Redirection 
number. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CFNL, Diverted-to user is subscribed to the 
COLR service in Permanent mode. 

Ensure that when user A calls user B, the call is forwarded not logged in to user 
C, a Redirection number restriction parameter is present set to 'Presentation 
restricted' in the encapsulated ANM contained in the 200 OK INVITE if 
ISUP/BICC- SIP-I interworking is applicable in Network A. 


Configuration 


Subscription options: 

• Connected user subscribed to COLR, Permanent = yes 


SIP Parameter 


200 OK 


Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

ANM 

Redirection number restriction 
Presentation restricted 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B), lAM ^ 
CFNL is performed 

4- INVITE(Call-ID B-C) 

1 80 Ringing (Call-ID C-B, ACM) ^ 
^ 180 Ringing (Call-ID B-A) 

200 OK INVITE (Call-ID C-B, ANM) ^ 
^ ACK (Call-ID B-C) 
^ 200 OK INVITE (Call-ID B-A) 

ACK (Call-ID A-B) ^ 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 

performs the diversion to a user in Network A 

Check: Is a 200 OK INVITE received at the interconnection interface 

Check: Is an ANM encapsulated in the 200 OK? 

Check: Is the ISUP/BICC Redirection number restriction set to 'Presentation 

restricted'? 
Repeat this test in reverse direction. 
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Test case number 


SS cfnl 015 


Test case group 


SIP-SIP/Service/CFNL 


Reference 


6.7/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 53 


Test purpose 


SIP-I support. CFNL performed in Network B, No restriction of the 
Redirection number. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CFNL, Diverted-to user is not subscribed to 
the COLR service. 

Ensure that when user A calls user B, the call is forwarded not logged in to user 
C, if a Redirection number restriction parameter is present it is set to 
'Presentation allowed' in the encapsulated ANM contained in the 200 OK INVITE 
if ISUP/BICC- SIP-I interworking is applicable in Network A. 


Configuration 


Subscription options: 

• Connected user subscribed to COLR = ho 


SIP Parameter 


200 OK 


Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

ANM 

Redirection number restriction 
Presentation allowed 
or 
Redirection number restriction not present 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B), lAM ^ 
CFNL is performed 

^ INVITE(Call-ID B-C) 

1 80 Ringing (Call-ID C-B, ACM) ^ 
^ 180 Ringing (Call-ID B-A) 

2flILQK INVITE (Call-ID C-B, ANM) ^ 
^ ACK (Call-ID B-C) 
^ 200 OK INVITE (Call-ID B-A) 

ACK (Call-ID A-B) ^ 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 

performs the diversion to a user in Network A 

Check: Is a 200 OK INVITE received at the interconnection interface? 

Check: Is an ANM encapsulated in the 200 OK? 

Check: Is the ISUP/BICC Redirection number restriction present set to 

'Presentation allowed' or is the parameter absent? 
Repeat this test in reverse direction. 



ETSI 



148 



ETSI TS 101 585 VI .1.2 (2012-09) 



Test case number 


SS cfnl 016 


Test case group 


SIP-SIP/Service/CFNL 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CFNL performed in Network B, Notification of diverted-to 
user Redirecting number 'presentation allowed'. 

The user A and user C are in Network A. The user B is in the PSTN/PLIVIN part 

of Network B and is provided with CFNL, Served user releases his/her number to 

diverted-to user = Release diverting number information. 

Ensure that when user A calls user B, the call is forwarded on Mobile subscriber 

not reachable to user 0, user is notified of call diversion and informed of the 

diverting number. 

The notification information is present in the encapsulated lAM contained in the 

Redirecting number 'presentation allowed' and Redirection information if 

ISUP/BIGG - SIP-I interworking is applicable in Network B. 


Configuration 


Subscription options: 


• Served user releases his/her number to diverted-to user = Release diverting 
number information 


SIP Parameter 


INVITE 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

lAM 

Redirecting number 

Address presentation restricted indicator 

presentation allowed 
Address signal (Diverting user) 
Original called number 

Address presentation restricted indicator 

presentation allowed 
Address signal 
Redirection information 

Original Redirection Reason 

unknown 
Redirecting indicator 
Redirection counter 
Redirecting reason 

Mobile subscriber not reachable 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFNL is performed 
^ P/ITE(Call-ID B-C, lAM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 

performs the diversion to a user in Network A 

Check: Is a INVITE request received at the interconnection interface? 

Check: Is an lAM encapsulated in the INVITE? 

Check: Is the Redirecting number present and the Address presentation 

restricted indicator is set to 'presentation allowed'? 
Check: Is the Original called number present and the Address presentation 

restricted indicator is set to 'presentation allowed'? 
Check: Is the Redirection number present? 
Check: Is Redirection information present and the Redirecting reason is set to 

'Mobile subscriber not reachable'? 
Repeat this test in reverse direction. 
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Test case number 


SS cfnl 017 


Test case group 


SIP-SIP/Service/CFNL 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CFNL performed in Network B, Notification of diverted-to 
user Redirecting number 'presentation restricted'. 

The user A and user C are in Network A. The user B is in the PSTN/PLIVIN part 

of Network B and is provided with CFNL, Served user releases his/her number to 

diverted-to user = Release diverting number information. 

Ensure that when user A calls user B, the call is forwarded on Mobile subscriber 

not reachable to user 0, user is notified of call diversion and informed of the 

diverting number. 

The notification information is present in the encapsulated lAM contained in the 

Redirecting number 'presentation restricted' and Redirection information if 

ISUP/BIGG - SIP-I interworking is applicable in Network B. 


Configuration 


Subscription options: 

• Served user releases his/her number to diverted-to user = Do not release 
diverting numberinformation 


SIP Parameter 


INVITE 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

lAM 

Redirecting number 

Address presentation restricted indicator 

presentation restricted 
Address signal (Diverting user) 
Original called number 

Address presentation restricted indicator 

presentation restricted 
Address signal 
Redirection information 

Original Redirection Reason 

unknown 
Redirecting indicator 
Redirection counter 
Redirecting reason 

Mobile subscriber not reachable 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CFNL is performed 
^ P/ITE(Call-ID B-C, lAM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 

performs the diversion to a user in Network A 

Check: Is a INVITE request received at the interconnection interface? 

Check: Is an lAM encapsulated in the INVITE? 

Check: Is the Redirecting number present and the Address presentation 

restricted indicator is set to 'presentation restricted'? 
Check: Is the Original called number present and the Address presentation 

restricted indicator is set to 'presentation restricted'? 
Check: Is the Redirection number present? 
Check: Is Redirection information present and the Redirecting reason is set to 

'Mobile subscriber not reachable'? 
Repeat this test in reverse direction. 
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7.1.5.6.5 



Communication Deflection 



Test case number 


SS cd 001 


Test case group 


SIP-SIP/Service/CD 


Reference 


4.5.2.6/f91 


SELECTION EXPRESSION 


SE29 


Test purpose 


Communication deflection during alerting, basic rules. 

The user A and user C are in Network A. The user B is in network B and is 
provided with CDa. 

Ensure that when user A calls user B, the call is deflected during alerting to user 
C. In the active call state, ensure the property of speech. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CDa is performed 

^ 180Ringing(Call-IDB-A) 
^ INVITE(Call-ID B-C) 

180Ringing(Call-IDC-B) ^ 
^ 180Ringing(Call-IDB-A) 

200 OK INVITE(Call-ID C-B) ^ 
^ ACK(Call-ID B-C) 
^ 200 OK INVITE(Call-ID B-A) 

ACK(Call-IDA-B) ^ 
Communication 
Apply post test routine 


Comments 


Check: CDa is successful. 

Check: In the active call state, ensure the property of speech. 

Check: Is the P-Asserted-ldentity present set to the identity of the originating 

user? 
Repeat this test in reverse direction. 



Test case number 


SS cd 002 


Test case group 


SIP-SIP/Service/CD 


Reference 


4.5.2.6/f91 


SELECTION EXPRESSION 


SE29 


Test purpose 


Communication deflection immediate, basic rules. 

Ensure that when user A calls user B which deflects the communication towards 
user C immediately (i.e. before alerting starts), the call is forwarded to user C. In 
the active call state, ensure the property of speech. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CDi is performed 
^ INVITE(Call-ID B-C) 

180Ringing(Call-IDC-B) ^ 
^ 180Ringing(Call-IDB-A) 

200 OK INVITE(Call-ID C-B) ^ 
^ ACK(Call-ID B-C) 
^ 200 OK INVITE(Call-ID B-A) 

ACK(Call-IDA-B) ^ 
Communication 
Apply post test routine 


Comments 


Check: CDi is successful. 

Check: In the active call state, ensure the property of speech. 

Check: Is the P-Asserted-ldentity present set to the identity of the originating 

user? 
Repeat this test in reverse direction. 
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Test case number 


SS cd 003 


Test case group 


SIP-SIP/Service/CD 


Reference 


4.5.2.6/f91 


SELECTION EXPRESSION 


SE 29 AND SE 30 


Test purpose 


Communication Deflection immediate response, no notification. 

The user A and user C are in Network A. The user B is in network B and is 
provided with CPU, subscription option: Originating user receives notification that 
his communication has been diverted = No. 

Ensure that when user A calls user B which deflects the communication towards 
user C immediately (i.e. before alerting starts), the call is forwarded to user C. 
Ensure that User A does not receive a 181 Call Is Being Porwarded message. 


Configuration 


Subscription options: 

• Originating user receives notification that his communication has been 
diverted = No 


SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CDi is performed 
^ INVITE(Call-ID B-C) 

180Ringing(Call-IDC-B) ^ 
^ 180Ringing(Call-IDB-A) 
Apply post test routine 


Comments 


Check: No notification regarding call forwarding in network B is received at the 

interconnection interface. 
Check: Is the cause parameter in the last entry is set to '480'. 
Repeat this test in reverse direction. 
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Test case number 


SS cd 004 


Test case group 


SIP-SIP/Service/CD 


Reference 


4.5.2.6/f91 


SELECTION EXPRESSION 


SE 29 AND SE 30 


Test purpose 


Communication Deflection immediate response, originating user is 
notified. URI of the diverted-to user not received. 

The user A and user C are in network A. The user B is in network B and is 
provided with CPU Originating user receives notification that his communication 
has been diverted = Yes and ("Served user allows the presentation of forwarded 
to URI to originating user in diversion notification" = No and. "Served user allows 
the presentation of his/her URI to originating user in diversion notification" = No. 
Ensure that when user A calls user B which deflects the communication towards 
user C immediately (i.e. before alerting starts), the call is forwarded to user C. 
Ensure that User A receives a 181 Call Is Being Forwarded message, user A is 
notified of call diversion and not informed of the diverted-to number and served 
user number. 


Configuration 


Subscription options: 

• Originating user receives notification that his communication has been 
diverted = Yes 

• Originating user receives notification that his communication has been 
diverted = No 

• Served user allows the presentation of his/her URI to originating user in 
diversion notification = No 


SIP Parameter 


181 Being Forwarded 

History-Info: 

<sip:userB@networkB?Privacy=history&Reason=SIP;cause=302>;index=1, 
<sip: userG@networkA;cause=480?Privacy=history>;index=1 .1 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CDi is performed 
^ INVITE(Call-ID B-C) 
^ |81 Being Forwarded(Call-ID B-A) 
Apply post test routine 


Comments 


Check: A 181 Being Forwarded and a History-Info header is received at the 
interconnection interface in both entries in the History-Info header a 
Privacy header is escaped value 'history'. 

Check: Is the cause parameter in the last entry is set to '480'? 

NOTE: The history entries can be accumulated in "one" History-Info header 
or each history entry is present in one single History-Info header. 

Repeat this test in reverse direction. 
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Test case number 


SS cd 005 


Test case group 


SIP-SIP/Service/CD 


Reference 


4.5.2.6/f91 


SELECTION EXPRESSION 


SE 29 AND SE 30 


Test purpose 


Communication Deflection immediate response, originating user is 
notified. URI from the diverted-to user received. 

The user A and user C are in network 1 . The user B is in network N2 and is 
provided with CPU Originating user receives notification that his communication 
has been diverted = Yes and "Served user allows the presentation of forwarded 
to URI to originating user in diversion notification" =Yes. 
Ensure that when user A calls user B which deflects the communication towards 
user C immediately (i.e. before alerting starts), the call is forwarded to user C. 
Ensure that User A receives a 181 Call Is Being Forwarded message, user A is 
notified of call diversion and informed of the diverted-to number. 


Configuration 


Subscription options: 

• Originating user receives notification that his communication has been 
diverted = Yes 


diversion notification = Yes 


SIP Parameter 


,181 Being Forwarded 

History-Info: 

<sip:userB@networkB?Reason=SIP;cause=302>;index=1, 
<sip: userG@networkA;cause=480>;index=1 .1 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CDi is performed 
^ INVITE(Call-ID B-C) 
^ |81 Being Forwarded(Call-ID B-A) 
Apply post test routine 


Comments 


Check: A 181 Being Forwarded is received at the interconnection interface. 
Check: A History-Info header is contained in the 181 with the URI of the 

diverted-to user. 
Check: Is the cause parameter in the last entry is set to '480'? 
NOTE: The history entries can be accumulated in "one" History-Info header 

or each history entry is present in one single History-Info header. 
Repeat this test in reverse direction. 
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Test case number 


SS cd 006 


Test case group 


SIP-SIP/Service/CD 


Reference 


4.5.2.6/f91 


SELECTION EXPRESSION 


SE 29 AND SE 30 


Test purpose 


Communication Deflection immediate response, diverted-to user does not 
receive the URI of the served user. 

The user A and user C are in network A. The user B is in network B and is 
provided with CPU "Served user allows the presentation of his/her URI to the 
diverted-to user" = No. 

Ensure that when user A calls user B which deflects the communication towards 
user C immediately (i.e. before alerting starts), the call is forwarded to user C, 
user C is not informed of the forwarding number. 


Configuration 


Subscription options: 

• Served user allows the presentation of his/her URI to diverted-to user = No 


SIP Parameter 


INVITE 

Request line contains ';cause=480' 

Hi story- Info: 

<sip:userB@networkB?Privacy=history&Reason=SIP;cause=302>;index=1, 

<sip: userC@networkA;cause=480>;index=1 .1 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CDi is performed 
^ INVITE(Call-ID B-C) 
Apply post test routine 


Comments 


Check: A History-Info header is received in the INVITE contains the URI of 

user B (served user) at the interconnection interface and a Privacy 

header is escaped set to 'history'. 
Check: Is the 'cause' parameter present in the Request line sent to user C 

(diverted-to user) set to '480'. 
Check: Is the cause parameter in the last entry is set to '480'? 
NOTE: The history entries can be accumulated in "one" History-Info header 

or each history entry is present in one single History-Info header. 
Repeat this test in reverse direction. 
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Test case number 


SS cd 007 


Test case group 


SIP-SIP/Service/CD 


Reference 


4.5.2.6/f91 


SELECTION EXPRESSION 


SE 29 AND SE 30 


Test purpose 


Communication Deflection immediate response, diverted-to user receives 
the URI of the served user. 

The user A and user C are in network A. The user B is in network B and is 
provided with CPU "Served user allows the presentation of his/her URI to 
diverted-to user" = Yes. 

Ensure that when user A calls user B which deflects the communication towards 
user C immediately (i.e. before alerting starts), the call is forwarded to user C, 
user C is informed of the forwarding number. 


Configuration 


Subscription options: 

• Served user allows the presentation of his/her URI to diverted-to user = Yes 


SIP Parameter 


INVITE 

Request line contains ';cause=480' 

Hi story- Info: 

<sip:userB@networkB?Reason=SIP;cause=302>;index=1, 
<sip: userC@networkA;cause=480>;index=1 .1 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CDi is performed 
^ INVITE(Call-ID B-C) 
Apply post test routine 


Comments 


Check: A History-Info header is received in the INVITE contains the URI of 
user B (served user) at the interconnection interface. 

Check: Is the 'cause' parameter present in the Request line sent to user C 
(diverted-to user) set to '480'? 

Check: Is the cause parameter in the last entry is set to '480'? 

NOTE: The history entries can be accumulated in "one" History-Info header 
or each history entry is present in one single History-Info header. 

Repeat this test in reverse direction. 



Test case number 


SS cd 008 


Test case group 


SIP-SIP/Service/CD 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE29 


Test purpose 


Communication Deflection immediate response, unsuccessful UDUB. 

The user A and user are in network A. The user B is in network B and is 
provided with GDI. 

Ensure that when user A calls user B, the call is deflected immediate to user G 
user G is user determined user busy. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CDi is performed 

^ INVITE(Call-ID B-C) 

486 Busy Here(Call-ID C-B) ^ 

^ ACK(Call-ID B-C) 

^ 486 Busy Here(Gall-ID B-A) 

AGK(Gall-IDA-B) ^ 
Apply post test routine 


Comments 


Check: The dialogue is terminated by receiving a 486 Busy Here. 
Repeat this test in reverse direction. 
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Test case number 


SS cd 009 


Test case group 


SIP-SIP/Service/CD 


Reference 


4.5.2.6/f9] 


SELECTION EXPRESSION 


SE29 


Test purpose 


Communication Deflection immediate response, unsuccessful NDUB. 

The user A and user C are in network A. The user B is in network B. 

Ensure that when user A calls user B, the call is deflected immediate to user C 

and user C is network determined user busy. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
CDi is performed 

^ INVITE(Gall-ID B-C) 

486 Busy Here(Gall-ID C-B) ^ 

^ ACK(Call-ID B-C) 

^ 486 Busy Here(Call-ID B-A) 

ACK(Call-IDA-B) ^ 
Apply post test routine 


Comments 


Check: The dialogue is terminated by receiving a 486 Busy Here. 
Repeat this test in reverse direction 



Test case number 


SS cd 010 


Test case group 


SIP-SIP/Service/GD 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE 29 AND SE 30 AND [Network A] SE 9 


Test purpose 


Communication Deflection immediate response, interaction with a not 
trusted network. 

The user A and user are in network A. The user B is in network B and is 
provided with CD Originating user receives notification that his communication 
has been diverted = Yes ("Served user allows the presentation of forwarded to 
URI to originating user in diversion notification"=Yes, "diverting number is 
released to the diverted-to user"=Yes. 

Ensure that when user A calls user B, the call is deflected immediate response 
to user 0, user A is notified of call diversion and not informed of the diverted-to 
number and user is not informed of the forwarding number. 


Configuration 




SIP Parameter 


Subscri 

• 

• 

• 
• 


ption options: 


diverted = Yes 

Served user allows the presentation of forwarded to URI to originating] 

user in diversion notification = No 

Served user allows the presentation of his/her URI to originating user in 

diversion notification = No 

Served user allows the presentation of his/her URI to the diverted-to 

user = No 


SIP Parameter 


INVITE: no History-Info header 


181 Being Forwarded no History-Info header 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(Gall-IDA-B) ^ 
CDi is performed 

INVITE(Call-ID B-C) 


^ 


181 Being Forwarded(Call-ID B-A) 


Apply post test routine 


Comments 


Check: No History-Info header is received in the INVITE at the interconnection 

interface. 
Check: No History-Info header is received in the 181 Being Forwarded at the 

interconnection interface. 
Repeat this test in reverse direction. 
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Test case number 


SS cd 011 


Test case group 


SIP-SIP/Service/CD 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B] SE 17 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CD performed in Network B, Notification subscription 
options is set to presentation not allowed. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 

of Network B and is provided with CDi or CDa, Calling user receives notification 

that his call has been diverted (forwarded or deflected) = yes, without diverted-to 

user number. 

Ensure that when user A calls user B, the call is deflected to user C, user A is 

not notified about call diversion. 

The notification information is present in the encapsulated ACM contained in the 

Redirection number and Call diversion information if SIP-I - ISUP/BICC 

interworking is applicable in Network B. 


Configuration 


Subscription options: 


• Calling user receives notification that his call has been diverted (forwarde(i 
or deflected) = no 


SIP Parameter 


183/180 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

ACM/CPG 

Redirection number 

Address signal (Diverted-to user) 
Call diversion information 

Notification subscription options 

presentation not allowed 
Redirecting reason 

Deflection immediate or Deflection during alerting 
Generic notification 
call is diverting 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
^ 180 Ringing (Call-ID B-A, ACM) in case CDa 

CD is performed 
^ INVITE(Call-ID B-C, lAM) 
^ 1 83 / 1 80 (Call-ID B-A, ACM/CPG) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 

performs the diversion to a user in Network A 

Check: Is a 183 Session Progress received at the interconnection interface? 

Check: Is an ACM encapsulated in the 1 83? 

Check: Is the Called party's status indicator set to 'no indication'? 

Check: Is the Redirection number present? 

Check: Is Notification subscription options indicator set to 'presentation not 

allowed'? 
Check: Is the Redirecting reason set to 'Deflection immediate' or 'Deflection 

during alerting'? 
Repeat this test in reverse direction. 
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Test case number 


SS cd 012 


Test case group 


SIP-SIP/Service/CD 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B] SE 17 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CD performed in Network B, Notification subscription 
options is set to presentation allowed without redirection number. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 

of Network B and is provided with CDi or CDa, Calling user receives notification 

that his call has been diverted (forwarded or deflected) = yes, without diverted-to 

user number. 

Ensure that when user A calls user B, the call is deflected to user C, user A is 

notified of call diversion and informed of the diverted-to number. 

The notification information is present in the encapsulated ACM contained in the 

Redirection number and Call diversion information if SIP-I - ISUP/BICC 

interworking is applicable in Network B. 


Configuration 


Subscription options: 


• Calling user receives notification that his call has been diverted (forwarde(i 
or deflected) = yes, without diverted-to user number 


SIP Parameter 


183/180 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

ACM/CPG 

Redirection number 

Address signal {Diverted-to user) 
Call diversion information 

Notification subscription options 

presentation allowed without redirection number 
Redirecting reason 

Deflection immediate or Deflection during alerting 
Generic notification 
call is diverting 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
^ 180 Ringing (Call-ID B-A) in case CDa 

CD is performed 
^ INVITE(Call-ID B-C, lAM) 
^ 1 83 / 1 80 (Call-ID B-A, ACM/CPG) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 

performs the diversion to a user in Network A 

Check: 183 Session Progress is received at the interconnection interface. 

Check: Is an ACM encapsulated in the 1 83? 

Check: Is the Called party's status indicator set to 'no indication'? 

Check: Is the Redirection number present? 

Check: Is Notification subscription options indicator is set to 'presentation 

allowed without redirection number'? 
Check: Is the Redirecting reason set to 'Deflection immediate' or 'Deflection 

during alerting'? 
Repeat this test in reverse direction. 
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Test case number 


SS cd 013 


Test case group 


SIP-SIP/Service/CD 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B] SE 17 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CD performed in Network B, Notification subscription 
options is set to presentation allowed with redirection number. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 

of Network B and is provided with CDi or CDa, Calling user receives notification 

that his call has been diverted (forwarded or deflected) = yes, with diverted-to 

user number. 

Ensure that when user A calls user B, the call is deflected to user C, user A is 

notified of call diversion and informed of the diverted-to number. 

The notification information is present in the encapsulated ACM contained in the 

Redirection number and Call diversion information if SIP-I - ISUP/BICC 

interworking is applicable in Network B. 


Configuration 


Subscription options: 


• Calling user receives notification that his call has been diverted (forwarde(i 
or deflected) = yes, with diverted-to user number 


SIP Parameter 


183/180 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

ACM/CPG 

Redirection number 

Address signal {Diverted-to user) 
Call diversion information 

Notification subscription options 

presentation allowed with redirection number 
Redirecting reason 

Deflection immediate or Deflection during alerting 
Generic notification 
call is diverting 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
^ 180 Ringing (Call-ID B-A) in case CDa 

CD is performed 
^ INVITE(Call-ID B-C, lAM) 
^ 1 83 / 1 80 (Call-ID B-A, ACM/CPG) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 

performs the diversion to a user in Network A 

Check: 183 Session Progress is received at the interconnection interface. 

Check: Is an ACM encapsulated in the 1 83? 

Check: Is the Called party's status indicator set to 'no indication'? 

Check: Is the Redirection number present? 

Check: Is Notification subscription options indicator is set to 'presentation 

allowed with redirection number'? 
Check: Is the Redirecting reason set to 'Deflection immediate' or 'Deflection 

during alerting'? 
Repeat this test in reverse direction. 
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Test case number 


SS cd 014 


Test case group 


SIP-SIP/Service/CD 


Reference 


6.7/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 53 


Test purpose 


SIP-I support. CD performed in Network B, Restriction of the Redirection 
number. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CDi or CDa, Diverted-to user is subscribed to 
the COLR service in Permanent mode. 

Ensure that when user A calls user B, the call is deflected to user C, a 
Redirection number restriction parameter is present set to 'Presentation 
restricted' in the encapsulated ANM contained in the 200 OK INVITE if 
ISUP/BICC- SIP-I interworking is applicable in Network A. 


Configuration 


Subscription options: 

• Connected user subscribed to COLR, Permanent = yes 


SIP Parameter 


200 OK 


Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

ANM 

Redirection number restriction 
Presentation restricted 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B), lAM ^ 
^ 180 Ringing (Call-ID B-A) in case CDa 

CD is performed 
^ INVITE(Call-ID B-C) 

1 80 Ringing (Call-ID C-B, ACM) ^ 
^ 180 Ringing (Call-ID B-A) 

200 OK INVITE (Call-ID C-B, ANM) ^ 
^ ACK (Call-ID B-C) 
^ 200 OK INVITE (Call-ID B-A) 

ACK (Call-ID A-B) ^ 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 

performs the diversion to a user in Network A 

Check: Is a 200 OK INVITE received at the interconnection interface? 

Check: Is an ANM encapsulated in the 200 OK? 

Check: Is the ISUP/BICC Redirection number restriction set to 'Presentation 

restricted'? 
Repeat this test in reverse direction. 
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Test case number 


SS cd 015 


Test case group 


SIP-SIP/Service/CD 


Reference 


6.7/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 53 


Test purpose 


SIP-I support. CD performed in Network B, No restriction of the Redirection 
number. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CDi or CDa, Diverted-to user is not subscribed 
to the COLR service. 

Ensure that when user A calls user B, the call is deflected to user C, if a 
Redirection number restriction parameter is present it is set to 'Presentation 
allowed' in the encapsulated ANM contained in the 200 OK INVITE if 
ISUP/BICC- SIP-I interworking is applicable in Network A. 


Configuration 


Subscription options: 

• Connected user subscribed to COLR = no 


SIP Parameter 


200 OK 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

ANM 

Redirection number restriction 
Presentation allowed 
or 
Redirection number restriction not present 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B), lAM ^ 
^ 180 Ringing (Call-ID B-A) in case CDa 

CD is performed 
^ INVITE(Call-ID B-C) 

1 80 Ringing (Call-ID C-B, ACM) ^ 
^ 180 Ringing (Call-ID B-A) 

200 OK INVITE (Call-ID C-B, ANM) ^ 
^ ACK (Call-ID B-C) 
^ 200 OK INVITE (Call-ID B-A) 

ACK (Call-ID A-B) ^ 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 

performs the diversion to a user in Network A 

Check: Is a 200 OK INVITE received at the interconnection interface? 

Check: Is an ANM encapsulated in the 200 OK? 

Check: Is the ISUP/BICC Redirection number restriction present set to 

'Presentation allowed' or is the parameter absent? 
Repeat this test in reverse direction. 
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Test case number 


SS cd 016 


Test case group 


SIP-SIP/Service/GD 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


[Network B] SE 17 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CD performed in Network B, Notification of diverted-to user 
Redirecting number 'presentation allowed'. 

The user A and user are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with GDI or CDa, Served user releases his/her 
number to diverted-to user = Release diverting number information. 
Ensure that when user A calls user B, the call is deflected to user 0, user is 
notified of call diversion and informed of the diverting number. 
The notification information is present in the encapsulated lAM contained in the 
Redirecting number 'presentation allowed' and Redirection information if 
ISUP/BIGG - SIP-I interworking is applicable in Network B. 


Configuration 


Subscription options: 

• Served user releases his/her number to diverted-to user = Release diverting 
number information 


SIP Parameter 


Gontent-Type: multipart/mixed;boundary=[any boundary name] 

--[any boundary name] 

Gontent-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

lAM 

Redirecting number 

Address presentation restricted indicator 

presentation allowed 
Address signal (Diverting user) 
Original called number 

Address presentation restricted indicator 

presentation allowed 
Address signal 
Redirection information 

Original Redirection Reason 

unknown 
Redirecting indicator 
Redirection counter 
Redirecting reason 

Deflection immediate or Deflection during alerting 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
^ 180 Ringing (Call-ID B-A) in case CDa 

CD is performed 
^ P/ITE(Call-ID B-C, lAM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 

performs the diversion to a user in Network A 

Check: Is a INVITE request received at the interconnection interface? 

Check: Is an lAM encapsulated in the INVITE? 

Check: Is the Redirecting number present and the Address presentation 

restricted indicator is set to 'presentation allowed'? 
Check: Is the Original called number present and the Address presentation 

restricted indicator is set to 'presentation allowed'? 
Check: Is the Redirection number present? 
Check: Is Redirection information present and the Redirecting reason is set to 

'Deflection immediate' or 'Deflection during alerting'? 
Repeat this test in reverse direction. 
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Test case number 


SS cd 017 


Test case group 


SIP-SIP/Service/GD 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


[Network B] SE 17 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CD performed in Network B, Notification of diverted-to user 
Redirecting number 'presentation restricted'. 

The user A and user are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with GDI or CDa, Served user releases his/her 
number to diverted-to user = Release diverting number information. 
Ensure that when user A calls user B, the call is deflected to user 0, user is 
notified of call diversion and informed of the diverting number. 
The notification information is present in the encapsulated lAM contained in the 
Redirecting number 'presentation restricted' and Redirection information if 
ISUP/BIGG - SIP-I interworking is applicable in Network B. 


Configuration 


Subscription options: 

• Served user releases his/her number to diverted-to user = Do not release 
diverting numberinformation 


SIP Parameter 


Gontent-Type: multipart/mixed;boundary=[any boundary name] 

--[any boundary name] 

Gontent-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

lAM 

Redirecting number 

Address presentation restricted indicator 

presentation restricted 
Address signal (Diverting user) 
Original called number 

Address presentation restricted indicator 

presentation restricted 
Address signal 
Redirection information 

Original Redirection Reason 

unknown 
Redirecting indicator 
Redirection counter 
Redirecting reason 

Deflection immediate or Deflection during alerting 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) ^ 
^ 180 Ringing (Call-ID B-A) in case CDa 

CD is performed 
^ P/ITE(Call-ID B-C, lAM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 

performs the diversion to a user in Network A 

Check: Is a INVITE request received at the interconnection interface? 

Check: Is an lAM encapsulated in the INVITE? 

Check: Is the Redirecting number present and the Address presentation 

restricted indicator is set to 'presentation restricted'? 
Check: Is the Original called number present and the Address presentation 

restricted indicator is set to 'presentation restricted'? 
Check: Is the Redirection number present? 
Check: Is Redirection information present and the Redirecting reason is set to 

'Deflection immediate' or 'Deflection during alerting'? 
Repeat this test in reverse direction. 
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7.1.5.7 



Conference (CONF) 



Test case number 


SS conf 001 


Test case group 


SIP-SIP/Service/CONF 


Reference 


4.5.2/[10] 


SELECTION EXPRESSION 


([Network A] SE 11 AND [Network B] SE 1 1) AND SE 31 


Test purpose 


3 Party establishment using the REFER method. 

User B1 and user 82 are located in network B, user A is located in network A. A 
confirmed session from user A to user 81 is set on hold; a confirmed session 
from user A to user B2 is set on hold. 

• Ensure that when user A refers to user B1 to invite to the conference, the 
user 81 sends a NOTIFY to user A indicating Tying'. The user B1 sends an 
INVITE request to the conference focus in network A. Is the request is 
confirmed, user B1 sends a NOTIFY indicating '200 OK'. User A terminates 
the original dialogue. 

• Ensure that when user A refers to user 82 to invite to the conference, the 
user B2 sends a NOTIFY to user A indicating 'Tying'. The user B2 sends an 
INVITE request to the conference focus in network A. Is the request is 
confirmed, user 82 sends a NOTIFY indicating '200 OK'. User A terminates 
the original dialogue. 


Configuration 




SIP Parameter 


REFER(userBI) 

Refer-To: <uri of conference focus;method=INVITE > 

N0TIFY(B1, 100) 

Content-Type: message/sipfrag 
SIP/2.0 100 

INVITE: Request URI: uri of conference focus 
From: user 81 

NOTIFY(B1,200) 

Content-Type: message/sipfrag 
SIP/2.0 200 OK 

hEFER(user B2) 

Refer-To: <uri of conference focus;method=INVITE > 

N0TIFY(B2, 100) 

Content-Type: message/sipfrag 
SIP/2.0 100 

INVITE: Request URI: uri of conference focus 
From: user B2 

N0TIFY(B2, 200) 

Content-Type: message/sipfrag 
SIP/2.0 200 OK 
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Message flow 






SIP (Network A) 


Interconnection Interface 


SIP (Network B) 


Establish a confirmed session to user B1 from Network A to Network B and put it on hold 


Establish a confirmed session to user 82 from Network A to Network B and put it on hold 


User A establishes a 3PTY conversation 






REFER(userBI) 


^ 


^ 


202 Accepted 




^ 


N0TIFY(B1, 100) 






200 OK NOTIFY 


^ 


^ 


INVITE(focus, userBI) 






200 INVITE 


^ 


^ 


ACK 




^ 


NOTIFY(B1,200) 






200 OK NOTIFY 


^ 




BYE(userBI) 


^ 


^ 


200 OK BYE 






REFER(user B2) 


^ 


^ 


202 Accepted 




^ 


NOTIFY(IOO) 






200 OK NOTIFY 


^ 


^ 


INVITE(focus, user B2) 






200 INVITE 


^ 


^ 


ACK 




^ 


N0TIFY(B2, 200) 






200 OK NOTIFY 


^ 




BYE(user B2) 


^ 


^ 


200 OK BYE 
Apply post test routine 




Comments 


User A establishes a 3PTY conversation after the confirmed communication to 




user B1 and B2 are set on hold 






Check: 


The Refer-To header in the REFER method sent to user B1 and B2 
contains the URI of the conference focus and is the method parameter 






set to 'INVITE'. 






Check: 


The NOTIFY after the REFER request contains the 'SIP/2.0 1 00' 






message body. 






Check: 


The INVITE request is sent by user 


B1 and user B2 to the conference 






focus the Request URI is used from the Refer-To header of the 






received REFER request. 






Check: 


The NOTIFY after the REFER request contains the 'SIP/2.0 200 OK' | 






message body. 






Check: 


The original session is terminated by user A. 




Repeat 


this test in reverse direction. 
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Test case number 


SS conf 002 


Test case group 


SIP-SIP/Service/CONF 


Reference 


4.5.2/[10], 4.7.2.9.7/[20] 


SELECTION EXPRESSION 


[Network A] SE 12 AND SE 31 


Test purpose 


3 Party establishment using relNVITE performed by the AS in network A. 

User B1 and user 82 are located in network B, user A is located in network A. A 
confirmed session from user A to user B1 is set on hold; a confirmed session 
from user A to user 82 is set on hold. 

• Ensure that user A can invite user B1 to the conference by sending a 
relNVITE request. 

• Ensure that user A can invite user B2 to the conference by sending a 
relNVITE request. 


Configuration 




SIP Parameter 


INVITE <B1> 
From: <userA> 
To: <userB1> 
Call-ID: A-B1 
P-Asserted-ldentity: <userA> 

SDP: a=sendrecv 

'INVITE <B2> 
From: <userA> 
Call-ID: A-B2 
To: <userB2> 
P-Asserted-ldentity: <userA> 

SDP: a=sendrecv 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

Establish a confirmed session to user B1 from Network A to Network B and put it on hold 

Establish a confirmed session to user B2 from Network A to Network B and put it on hold 

User A establishes a 3PTY conversation 

INVITE(Call-IDA-BI) ^ 
^ 200 INVITE 

ACK ^ 

INVITE(Call-IDA-B2) ^ 
^ 200 INVITE 

ACK ^ 
Apply post test routine 


Comments 


User A establishes a 3PTY conversation after the confirmed communication to 

user B1 and B2 are set on hold 

Check: An INVITE is sent to user B1 and user B2 indicating a new IP address 

in the 'c' line of the SDP. 
Check: The 'a' line indicates 'sendrecv'. 
Repeat this test in reverse direction. 
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Test case number 


SS conf 003 


Test case group 


SIP-SIP/Service/GONF 


Reference 


5.4/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 56 


Test purpose 


SIP-I/ISUP interworking. Served user establishes a 3 Party communication. 

Served User A is located in Network A and ISUP/BIGG - SIP-I interworking 
applies in Network A. User A establishes a confirmed communication with a User 
B1 in Network B and sets it on HOLD. User A establishes a confirmed 
communication with a User B2 in Network B. 
Ensure that when User A establishes a 3 PTY communication: 

• an INFO request is sent to User B1 in Network B and a ISUP/BIGG GPG 
is encapsulated the Generic Notification is set to 'conference 
established'; 

• an INFO request is sent to User B2 in Network B and a ISUP/BIGG GPG 
is encapsulated the Generic Notification is set to 'conference 
established'. 


Configuration 


ISUP/BIGG interworking applies in Network A 

User in Network A is subscribed to the 3PTY supplementary service 


SIP Parameter 


INF0<B1> 

Gontent-Type: application/isup;version=itu-t92 
Gontent-Disposition: signal;handling=required 

CPG 

Generic Notification 

Gonference established 

^■<B2> 

Gontent-Type: application/isup;version=itu-t92 
Gontent-Disposition: signal;handling=required 

CPG 

Generic Notification 

Gonference established 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

Establish a confirmed session from User A in Network A to user B1 in Network B and put it on hold 

Establish a confirmed session from User A in Network A to user B2 in Network B 

INF0(Call-IDA-B1,CPG) ^ 
^ 200 INFO 

INFO(Call-ID A-B2, CPG) ^ 
^ 200 INFO 

Apply post test routine 


Comments 


User A establishes confirmed communication to user B1 in Network B and sets it 

on hold 

User A establishes a confirmed communication to user B2 in Network B 

User A invokes the 3PTY communication 

Check: Is an INFO request sent to user B1 and user B2 in Network B? 

Check: Is a ISUP/BIGG GPG message encapsulated in the INFO request to 

both remote users in Network B? 
Check: Is the Generic Notification parameter in the encapsulated GPG in both 

INFO set to 'Gonference established'? 
Repeat this test in reverse direction. 
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Test case number 


SS conf 004 


Test case group 


SIP-SIP/Service/GONF 


Reference 


5.4/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 56 


Test purpose 


SIP-I/ISUP interworking. Served user disconnects one of the remote users. 

Served User A is located in Network A and ISUP/BIGG - SIP-I interworking 
applies in Network A. User A establishes a confirmed communication with a User 
B1 in Network B and sets it on HOLD. User A establishes a confirmed 
communication with a User B2 in Network B. User A invokes 3PTY conversation. 
Ensure that when User A disconnects the previous active user: 

• a BYE request is sent to User B1 in Network B; 

• an INFO request is sent to User B2 in Network B and a ISUP/BICC CPG 
is encapsulated the Generic Notification is set to 'Conference 
disconnected'. 


Configuration 


ISUP/BICC interworking applies in Network A 

User in Network A is subscribed to the 3PTY supplementary service 


SIP Parameter 


INFO <B2> 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

CPG 

Generic Notification 

Conference disconnected 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

Establish a confirmed session from User A in Network A to user B1 in Network B and put it on hold 

Establish a confirmed session from User A in Network A to user B2 in Network B 

User A establishes a 3PTY conversation 

BYE(Call-IDA-B1,REL) ^ 
^ 200 INFO 

INFO(Call-ID A-B2, CPG) ^ 
^ 200 INFO 

Apply post test routine 


Comments 


User A establishes a 3PTY conversation with user B1 and user B2 located in 

Network B 

User A disconnects the communication with user B1 in Network B (previous on 

hold) 

Check: Is a BYE request is sent to user B1 in Network B? 

Check: Is a ISUP/BICC CPG message encapsulated in the INFO request to 

user B2 in Network B? 
Check: Is the Generic Notification parameter in the encapsulated CPG in the 

INFO sent to user B2 set to 'Conference disconnected'? 
Repeat this test in reverse direction. 
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Test case number 


SS conf 005 


Test case group 


SIP-SIP/Service/GONF 


Reference 


5.4/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 56 


Test purpose 


SIP-I/ISUP interworking. Served user splits the 3 Party communication. 

Served User A is located in Network A and ISUP/BIGG - SIP-I interworking 
applies in Network A. User A establishes a confirmed communication with a User 
B1 in Network B and sets it on HOLD. User A establishes a confirmed 
communication with a User B2 in Network B. User A invokes 3PTY conversation 
Ensure that when User A splits the 3 PTY communication: 

• an INFO request is sent to User B1 in Network B and a ISUP/BIGG GPG 
is encapsulated the Generic Notification is set to 'Gonference 
disconnected'; 

• an INFO request is sent to User B2 in Network B and a ISUP/BIGG GPG 
is encapsulated the Generic Notification is set to 'Gonference 
disconnected'. 


Configuration 


ISUP/BIGG interworking applies in Network A 

User in Network A is subscribed to the 3PTY supplementary service 


SIP Parameter 


INF0<B1> 

Gontent-Type: application/isup;version=itu-t92 
Gontent-Disposition: signal;handling=required 

CPG 

Generic Notification 

Gonference disconnected 

^■<B2> 

Gontent-Type: application/isup;version=itu-t92 
Gontent-Disposition: signal;handling=required 

CPG 

Generic Notification 

Gonference disconnected 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

Establish a confirmed session from User A in Network A to user B1 in Network B and put it on hold 

Establish a confirmed session from User A in Network A to user B2 in Network B 

User A establishes a 3PTY conversation 

INF0(Call-IDA-B1,CPG) ^ 
^ 200 INFO 

INF0(Call-IDA-B2, CPG) ^ 
^ 200 INFO 

Apply post test routine 


Comments 


User A establishes confirmed communication to user B1 in Network B and sets it 
on hold 

User A establishes a confirmed communication to user B2 in Network B 
Check: Is an INFO request sent to user B1 and user B2 in Network B? 
Check: Is a ISUP/BIGG GPG message encapsulated in the INFO request to 

both remote users in Network B? 
Check: Is the Generic Notification parameter in the encapsulated GPG in both 

INFO set to 'Gonference established'? 
Repeat this test in reverse direction. 
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Test case number 


SS conf 006 


Test case group 


SIP-SIP/Service/CONF 


Reference 


5.4/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 56 


Test purpose 


SIP-I/ISUP interworking. Establishment of aCONF conversation. 

Served User A is located in Network A and ISUP/BICC - SIP-I interworking 
applies in Network A. User A establishes a confirmed communication with a User 
B1 in Network B and invokes the CONF communication. 
Ensure that when User A invokes the CONF communication: 

• an INFO request is sent to User B1 in Network B and a ISUP/BICC CPG 
is encapsulated the Generic Notification is set to 'conference 
established' when the conference is invoked. 

User A establishes a confirmed communication with a User B2 in Network B. 
Ensure when User A adds the user B2 to the established conference: 

• an INFO request is sent to User B1 in Network B and a ISUP/BICC CPG 
is encapsulated the Generic Notification is set to 'Other party; 

• an INFO request is sent to User B2 in Network B and a ISUP/BICC CPG 
is encapsulated the Generic Notification is set to 'conference 
established' when the user is added to the conference. 


Configuration 


ISUP/BICC interworking applies in Network A 

User in Network A is subscribed to the 3PTY supplementary service 


SIP Parameter 


1L1£P1 <B1> 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

CPG 

Generic Notification 

conference established 

INF02<B1> 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

CPG 

Generic Notification 
Other party added 

[NFO <B2> 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

Generic Notification 

conference established 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

Establish a confirmed session from User A in Network A to user B1 in Network B 

User A establishes a CONF conversation 

INF01 (Call-ID A-B1,CPG) ^ 
^ 200 INFO 

Establish a confirmed session from User A in Network A to user B2 in Network B and add to the 

conference 

INF02(Call-IDA-B2, CPG) ^ 
^ 200 INFO 

INF0(Call-IDA-B2, CPG) ^ 
^ 200 INFO 

Apply post test routine 
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Comments 


User A establishes confirmed communication to user B1 in Network B and 

invoke the CONF communication 

Check: Is an INFO request sent to user 81 and in Network B and Is a 

ISUP/BICC CPG message encapsulated in the INFO request and the 

Generic Notification is set to 'conference established'? 
User A establishes a confirmed communication to user B2 in Network B and add 
it to the conference. 
Check: Is an INFO request sent to user B2 Network B and a ISUP/BICC CPG 

message encapsulated the Generic Notification is set to 'conference 

established'? 
Check: Is an INFO request sent to user B1 Network B and a ISUP/BICC CPG 

message encapsulated the Generic Notification is set to 'Other party 

added? 
Repeat this test in reverse direction. 



Test case number 


SS conf 007 


Test case group 


SIP-SIP/Service/CONF 


Reference 


5.4/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 56 


Test purpose 


SIP-I/ISUP interworking. Isolation and Reattachment of one party of the 
conference. 

Served User A is located in Network A and ISUP/BICC - SIP-I interworking 

applies in Network A. User A invokes a CONF communication with user B1 and 

user B2 in Network B. 

Ensure that when User A isolates one remote party (B1) from the CONF 

communication: 

• an INFO request is sent to User B1 in Network B and the Generic 
Notification is set to 'isolated' in the encapsulated ISUP/BICCCPG; 

• an INFO request is sent to User B2 in Network B and the Generic 
Notification is set to 'Other party isolated' in the encapsulated 
ISUP/BICCCPG. 

Ensure that when User A reattaches one remote party (B1) to the CONF 
communication: 

• an INFO request is sent to User B1 in Network B and the Generic 
Notification is set to 'reattached' in the encapsulated ISUP/BICCCPG; 

• an INFO request is sent to User B2 in Network B and the Generic 
Notification is set to 'Other party reattached' in the encapsulated 
ISUP/BICCCPG. 


Configuration 


ISUP/BICC interworking applies in Network A 

User in Network A is subscribed to the 3PTY supplementary service 


SIP Parameter 


iNFOl <B1> 

CPG 

Generic Notification= isolated 

TnFn5<Bi> 

CPG 

Generic Notification= Other party isolated 

fNF01 <B2> 

CPG 

Generic Notification= reattached 

iNF02 <B2> 


CPG 

Generic Notification= Other party reattached 
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Message flow 




SIP (Network A) 


Interconnection Interface SIP (Network B) 


Establish 


a CONF communication with User B1 and User 82 in Network B 




User A isolates User 81 from the CONF conversation 




INF01(Call-IDA-B1,CPG) ^ 




^ 200 INFO 




INF01 (Call-ID A-B2,CPG) ^ 




^ 200 INFO 




User A reattaches User B1 to the CONF conversation 




INF02(Gall-IDA-B2, CPG) ^ 




^ 200 INFO 




INF02(Gall-ID A-B2, CPl) ^ 




^ 200 INFO 




Apply post test routine 


Comments 




User A Invokes a GONF conversation with User B1 and User b2 in Network B 

User A splits user B1 in Network B from the GONF conversation 

Check: Is an INFO request sent to user B1 and the Generic notification is set 

to 'isolated' in the encapsulated GPG? 
Check: Is an INFO request sent to user B2 and the Generic notification is set 

to 'Other party isolated' in the encapsulated GPG? 
User A reattaches user B1 in Network B to the GONF conversation 
Check: Is an INFO request sent to user B1 and the Generic notification is set 

to 'reattached' in the encapsulated GPG? 
Check: Is an INFO request sent to user B2 and the Generic notification is set 

to 'Other party reattached' in the encapsulated GPG? 
Repeat this test in reverse direction 
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Test case number 


SS conf 008 


Test case group 


SIR-SIR/Service/GONF 


Reference 


5.4/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 56 


Test purpose 


SIP-I/ISUP interworking. Splitting and Adding of a party. 

Served User A is located in Network A and ISUR/BICC - SIR-I interworking 

applies in Network A. User A invokes a CONF communication with user B1 and 

user B2 in Network B. 

Ensure that when User A split one remote party (B1) from the CONF 

communication: 

• an INFO request is sent to User B1 in Network B and the Generic 
Notification is set to 'conference disconnected' in the encapsulated 
ISUR/BICCCRG; 

• an INFO request is sent to User B2 in Network B and the Generic 
Notification is set to 'Other party split' in the encapsulated 
ISUR/BICCCRG. 

Ensure that when User A adds one remote party (B1) to the CONF 
communication: 

• an INFO request is sent to User B1 in Network B and the Generic 
Notification is set to 'Conference established' in the encapsulated 
ISUR/BICCCRG; 

• an INFO request is sent to User B2 in Network B and the Generic 
Notification is set to 'Other party added' in the encapsulated 
ISUR/BICCCRG. 


Configuration 


ISUR/BICC interworking applies in Network A 

User in Network A is subscribed to the 3RTY supplementary service 


SIP Parameter 


INF01 <B1> 

CPG 

Generic Notification= conference disconnected 

■|NF02<B1> 

CPG 

Generic Notification=Other party split 

^■<B2> 

CPG 

Generic Notification=Conference established 

|liiii<B2> 

CPG 

Generic Notification= Other party added 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

Establish a CONF communication with User B1 and User 82 in Network B 

User A isolates User 81 from the CONF conversation 

INF01(Call-IDA-B1,CPG) ^ 
^ 200 INFO 

INF01 (Call-ID A-B2,CPG) ^ 
^ 200 INFO 
User A reattaches User B1 to the CONF conversation 

INF02(Call-IDA-B2, ORG) ^ 
^ 200 INFO 

INF02(Gall-IDA-B2, ORG) ^ 
^ 200 INFO 

Apply post test routine 


Comments 


User A Invokes a CONF conversation with User B1 and User b2 in Network B 

User A splits user B1 in Network B from the CONF conversation. 

Check: Is an INFO request sent to user B1 and the Generic notification is set 

to 'conference disconnected' in the encapsulated CRG? 
Check: Is an INFO request sent to user B2 and the Generic notification is set 

to 'Other party split' in the encapsulated CRG? 
User A adds user B1 in Network B to the CONF conversation. 
Check: Is an INFO request sent to user B1 and the Generic notification is set 

to 'Conference established' in the encapsulated CRG? 
Check: Is an INFO request sent to user B2 and the Generic notification is set 

to 'Other party added' in the encapsulated CRG? 
Repeat this test in reverse direction 
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7.1 .5.8 Anonymous Communication Rejection (ACR) and Communication Barring 

(CB) 



Test case number 


SS acr-cb 001 


Test case group 


SIP-SIP/Service/AGR-GB 


Reference 


4.5.2.6/[12] 


SELECTION EXPRESSION 


SE32 


Test purpose 


Call Barring performed in network B for user B. 

User A is located in network A and user B is located in network B and is 
subscribed to the Incoming Call Barring service. 

Ensure that a communication from user A is rejected in network B by sending a 
603 Decline due to the Call Barring service of user B. 


Configuration 


User B is subscribed to the incoming Call Barring service (e.g. user A in a black 
list) 


SIP Parameter 


INVITE 

P-Asserted-ldentity: <URI of user A> 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 603 (Decline) 

ACK ^ 


Comments 


Check: Is the P-Asserted-ldentity present? 

Check: Is the communication rejected by sending a 603 (Decline) final 

response sent to user A? 

Repeat this test in reverse direction. 



Test case number 


SS acr-cb 002 


Test case group 


SIP-SIP/Service/ACR-CB 


Reference 


4.5.2.6/[12] 


SELECTION EXPRESSION 


SE33 


Test purpose 


ACR performed in network B for user B. 

User A is located in network A and user B is located in network B and is 
subscribed to the Anonymous Communication rejection service. 
Ensure that an anonymous communication from user A is rejected in network B 
by sending a 403 Anonymity Disallowed final response due to the Anonymous 
Communication Rejection service of user B. 


Configuration 


User B is subscribed to the Anonymous Communication Rejection service 


SIP Parameter 


INVITE 

P-Asserted-ldentity: <URI of user A> 
Privacy: id 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
4- 433 (Anonymity Disallowed) 

ACK ^ 


Comments 


Check: Is the P-Asserted-ldentity present? 

Check: Is the Privacy header set to 'id'? 

Check: Is the communication rejected by sending a 433 (Anonymity 

Disallowed) final response sent to user A? 
Repeat this test in reverse direction. 



ETSI 



175 



ETSI TS 101 585 VI .1.2 (2012-09) 



Test case number 


SS acr-cb 003 


Test case group 


SIP-SIP/Service/ACR-CB 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 57 


Test purpose 


SIP-I interworking. ACR performed in network B for user B. 

User A is located in network A and user B is in the PSTN/PLMN part of Network 
B and is subscribed to the Anonymous Communication rejection service. 
Ensure that an anonymous communication from user A is rejected in network B 
by sending a 603 Decline final response due to the Anonymous Communication 
Rejection service of user B. A ISUP/BICC REL is present in the 603 the Cause 
indicator value is set to '21 ' if SIP-I - ISUP/BICC interworking is applicable in 
Network B. 


Configuration 


User B is subscribed to the Anonymous Call Rejection service 


SIP Parameter 


INVITE 

P-Asserted-ldentity: <URI of user A> 
Privacy: id 

433 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

REL: 

Cause indicator 
Cause = 21 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 603 Decline (REL) 

ACK ^ 


Comments 


Check: Is the P-Asserted-ldentity present? 

Check: Is the Privacy header set to 'id'? 

Check: Is the communication rejected by sending a 603 Decline final 

response sent to user A? 
Check: Is an ISUP/BICC REL is present in the 603 and the cause value is set 

to '21'? 
Repeat this test in reverse direction. 
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7.1.5.9 



Closed User Group (CUG) 



Test case number 


SS cug 001 


Test case group 


SIP-SIP/Service/CUG 


Reference 


4.5.2.4/[13] 


SELECTION EXPRESSION 


SE34 


Test purpose 


Originating user +0A to terminating user no CUG. 

An originating user in a CUG Outgoing Access allowed calls to a user not in a 
CUG. The session establishment is successful. 


Configuration 


Originating user: CUG, outgoing access allowed 


SIP Parameter 


INVITE: 

Content-Type: application/vnd.etsi.cug+xml 

<...cug> 

<...networklndicator>01</... networklndicator 

<. . .networklndicator>23</. . . networklndicator 

<. . . .cuglnterlockBinaryCode>0F03</. . .cuglnterlockBinaryCode> 

<. . .CugCommunicationlndicator>1 0</. . .cugCommunicationlndicator> 

<...:cug> 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 180 Ringing 

Apply post test routine 


Comments 


Check: Is the Content-Type in The INVITE set to 

application/vnd.etsi.cug+xml? 
Check: Contains the XML body in the INVITE a 'cug' element? 
Check: Contains the XML body in the INVITE a 'networklndicator' element as 

a 'cug' child element? 
Check: Contains the XML body in the INVITE a 'cuglnterlockBinaryCode' 

element as a 'cug' child element? 
Check: Contains the XML body in the INVITE a 'cugCommunicationlndicator' 

element set to '1 0' as a 'cug' child element? 
Check: Is the session setup not rejected? 
Repeat this test in reverse direction. 
NOTE: The networklndicator element value and the cuglnterlockBinaryCode 

element value are examples. 
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Test case number 


SS cug 002 


Test case group 


SIP-SIP/Service/CUG 


Reference 


4.5.2.4, 4.5.2.10/[13] 


SELECTION EXPRESSION 


SE34 


Test purpose 


Originating user -OA to terminating user no CUG. 

An originating user in a CUG Outgoing Access not allowed calls to a user not in 
a CUG. The session establishment is not successful, a 403 (Forbidden) 
response is sent. 


Configuration 


Originating user: CUG, outgoing access not allowed 


SIP Parameter 


INVITE: 

Content-Type: application/vnd.etsi.cug+xml 
Content-Disposition: ....;handling= required 

<...:cug> 

<. . .networklndicator>01 </. . .networklndicator 

<. . .networklndicator>23</. . .networklndicator 

<. . . .uglnterlockBinaryCode>0F03</. . .cuglnterlockBinaryCode> 

<. . .cugCommunicationlndicator>1 1 </. . .cugCommunicationlndicator> 

<...cug> 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 403 (Forbidden) 

ACK ^ 


Comments 


Check: Is the Content-Type in The INVITE set to 

application/vnd.etsi.cug+xml? 
Check: Is the handling parameter in the Content-Disposition header set to 

required? 
Check: Contains the XML body in the INVITE a 'cug' element? 
Check: Contains the XML body in the INVITE a 'networklndicator' element as 

a 'cug' child element? 
Check: Contains the XML body in the INVITE a 'cuglnterlockBinaryCode' 

element as a 'cug' child element? 
Check: Contains the XML body in the INVITE a 'cugCommunicationlndicator' 

element set to '11 ' as a 'cug' child element? 
Check: Is the session setup rejected? A 403 (Forbidden) final response is sent 

by the terminating network? 
Repeat this test in reverse direction. 
NOTE: The networklndicator element value and the cuglnterlockBinaryCode 

element value are examples. 
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Test case number 


SS cug 003 


Test case group 


SIP-SIP/Service/CUG 


Reference 


4.5.2.4, 4.5.2.10/[13] 


SELECTION EXPRESSION 


SE34 


Test purpose 


Originating user -OA to terminating user -lA. 

An originating user in a CUG Outgoing Access not allowed calls to a user in the 
same CUG Incoming Access not allowed. The session establishment is 
successful. 


Configuration 


Originating user: CUG, outgoing access not allowed 
Terminating user: CUG incoming access not allowed 
User in network A and user in network B are in the same CUG 


SIP Parameter 


INVITE: 

Content-Type: application/vnd.etsi.cug+xml 
Content-Disposition: ....;handling= required 

<...cug> 

<. . .networklndicator>01 </. . .networklndicator 

<. . .networklndicator>23</. . .networklndicator 

<. . .cuglnterlockBinaryCode>0F03</. . .cuglnterlockBinaryCode> 

<. . .cugCommunicationlndicator>1 1 </. . .cugCommunicationlndicator> 

<...cug> 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 180 Ringing 

Apply post test routine 


Comments 


Check: Is the Content-Type in The INVITE set to 

application/vnd.etsi.cug+xml? 
Check: Is the handling parameter in the Content-Disposition header set to 

required? 
Check: Contains the XML body in the INVITE a 'cug' element? 
Check: Contains the XML body in the INVITE a 'networklndicator' element as 

a 'cug' child element? 
Check: Contains the XML body in the INVITE a 'cuglnterlockBinaryCode' 

element as a 'cug' child element? 
Check: Contains the XML body in the INVITE a 'cugCommunicationlndicator' 

element set to '11 ' as a 'cug' child element? 
Check: Is the session setup not rejected? 
Repeat this test in reverse direction. 
NOTE: The networklndicator element value and the cuglnterlockBinaryCode 

element value are examples. 
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Test case number 


SS cug 004 


Test case group 


SIP-SIP/Service/CUG 


Reference 


4.5.2.4, 4.5.2.10/[13] 


SELECTION EXPRESSION 


SE34 


Test purpose 


Originating user in a CUG to terminating user -lA. 

An originating user in a CUG calls to a user in a different CUG Incoming Access 
not allowed. The session establishment is not successful, a 403 (Forbidden) 
response is sent. 


Configuration 


User in network A and user in network B are not in the same CUG 
Terminating user: CUG incoming access not allowed 


SIP Parameter 


INVITE: 

Content-Type: application/vnd.etsi.cug+xml 
Content-Disposition: ....;handling= requiredv 

<...cug> 

<. . .networklndicator>01 </. . .networklndicator 

<. . .networklndicator>23</. . .networklndicator 

<. . .cuglnterlockBinaryCode>0F03</. . .cuglnterlockBinaryCode> 

<. . .cugCommunicationlndicator>..</. . .cugCommunicationlndicator> 
<...cug> 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 403 (Forbidden) 

ACK ^ 


Comments 


Check: Is the Content-Type in The INVITE set to 

application/vnd.etsi.cug+xml? 
Check: Contains the XML body in the INVITE a 'cug' element? 
Check: Contains the XML body in the INVITE a 'networklndicator' element as 

a 'cug' child element? 
Check: Contains the XML body in the INVITE a 'cuglnterlockBinaryCode' 

element as a 'cug' child element? 
Check: Contains the XML body in the INVITE a 'cugCommunicationlndicator' 

element set to '1 0' or '1 1 'as a 'cug' child element? 
Check: Is the session setup rejected? A 403 (Forbidden) final response is sent 

by the terminating network? 
Repeat this test in reverse direction. 
NOTE: The networklndicator element value and the cuglnterlockBinaryCode 

element value are examples. 



Test case number 


SS cug 005 


Test case group 


SIP-SIP/Service/CUG 


Reference 


4.5.2.1 0/[1 3] 


SELECTION EXPRESSION 


SE34 


Test purpose 


Originating user no CUG to terminating user +IA. 

An originating user not in a CUG calls to a user in a CUG Incoming Access 
allowed. The session establishment is successful. 


Configuration 


Terminating user: CUG incoming access allowed 


SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 180 Ringing 

Apply post test routine 


Comments 


Check: Is the session setup rejected? A 403 (Forbidden) final response is sent 

by the terminating network. 
Repeat this test in reverse direction. 
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Test case number 


SS cug 006 


Test case group 


SIP-SIP/Service/CUG 


Reference 


4.5.2.1 0/[1 31 


SELECTION EXPRESSION 


[Network A] SE 34 AND NOT [Network B] SE 34 


Test purpose 


Originating user no CUG to terminating user -lA. 

An originating user not in a CUG calls to a user in a CUG Incoming Access not 
allowed. The session establishment is not successful, a 403 (Forbidden) 
response is sent. 


Configuration 


User in Network B in a CUG incoming access not allowed 


SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 403 (Forbidden) 

ACK ^ 


Comments 


Check: Is the session setup rejected? A 403 (Forbidden) final response is sent 

by the terminating network. 
Repeat this test in reverse direction. 



Test case number 


SS cug 007 


Test case group 


SIP-SIP/Service/CUG 


Reference 


4.5.2.4/[13l 


SELECTION EXPRESSION 


SE34 


Test purpose 


Originating user -OA, network B does not support CUG. 

An originating user in a CUG Outgoing Access not allowed calls to a user in 
network B. Network B does not support CUG. The session establishment is not 
successful, a 4xx unsuccessful final response is sent. 


Configuration 




SIP Parameter 


INVITE: 

Content-Type: application/vnd.etsi.cug+xml 
Content-Disposition: ....;handling= required 

<...cug> 

<. . .networklndicator>01 </. . .networklndicator 

<. . .networklndicator>23</. . .networklndicator 

<. . .cuglnterlockBinaryCode>0F03</. . .cuglnterlockBinaryCode> 

<. . .cugCommunicationlndicator>1 0</. . .cugCommunicationlndicator> 

<...cug> 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
4- 4xx/501 Not Implemented 

ACK ^ 


Comments 


Check: Is the Content-Type in The INVITE set to 

application/vnd.etsi.cug+xml? 
Check: Is the handling parameter in the Content-Disposition header set to 

required? 
Check: Contains the XML body in the INVITE a 'cug' element? 
Check: Contains the XML body in the INVITE a 'networklndicator' element as 

a 'cug' child element? 
Check: Contains the XML body in the INVITE a 'cuglnterlockBinaryCode' 

element as a 'cug' child element? 
Check: Contains the XML body in the INVITE a 'cugCommunicationlndicator' 

element set to '11 ' as a 'cug' child element? 
Check: Is the session setup rejected by sending an unsuccessful final 

response? 
Repeat this test in reverse direction. 
NOTE: The networklndicator element value and the cuglnterlockBinaryCode 

element value are examples. 
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Test case number 


SS cug 008 


Test case group 


SIP-SIP/Service/CUG 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 58 


Test purpose 


SIP-I/ISUP interworking. CUG call with outgoing access allowed. 

User A is located in the PSTN part of Network A and ISUP/BICC interworking 
applies in Network A. ensure that when user A is in a CUG 'outgoing access 
allowed' calls user B in Network B. The call is successful. There is a Optional 
forward call indicator the CUG Gall Indicator Outgoing access allowed present 
in the encapsulated lAM sent to Network B. 


Configuration 


• User in PSTN/PLMN part of Network A in a CUG outgoing access allowed 


SIP Parameter 


INVITE 

Content-Type: multipart/mixed;boundary=[any boundary name] 

--[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

lAM 

Optional Forward call indicator 

CUG Call Indicator 

Outgoing access allowed 
CUG interlock code 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 180 Ringing 


Comments 


User A in the PSTN part of Network A calls user B in Network B 

Check: Is an lAM encapsulated in the INVITE request sent from Network A to 

Network B? 
Check: Is the Optional forward call indicator present, the CUG Call Indicator is 

set to 'Outgoing access allowed'? 
Check: Is the CUG interlock code parameter present in the encapsulated 

lAM? 
NOTE: CUG outgoing access allowed can appear like a basic call. 
Repeat this test in reverse direction. 
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Test case number 


SS cug 009 


Test case group 


SIP-SIP/Service/CUG 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 58 


Test purpose 


SIP-I/ISUP interworking. CUG call with outgoing access not allowed. 

User A is located in the PSTN part of Network A and ISUP/BICC interworking 
applies in Network A. ensure that when user A is in a CUG 'outgoing access 
allowed' calls user B in Network B. The call is successful. There is a Optional 
forward call indicator the CUG Gall Indicator Outgoing access not allowed 
present in the encapsulated lAM sent to Network B. 


Configuration 


• User in PSTN/PLMN part of Network A in a CUG outgoing access not 
allowed 


SIP Parameter 


INVITE 

Content-Type: multipart/nnixed;boundary=[any boundary name] 

--[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

lAM 

Optional Forward call indicator 

CUG Call Indicator 

Outgoing access not allowed 
CUG interlock code 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 180 Ringing 


Comments 


User A in the PSTN part of Network A calls user B in Network B 

Check: Is an lAM encapsulated in the INVITE request sent from Network A to 

Network B? 
Check: Is the Optional forward call indicator present, the CUG Call Indicator is 

set to 'Outgoing access not allowed'? 
Check: Is the CUG interlock code parameter present in the encapsulated 

lAM? 
Repeat this test in reverse direction. 
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Test case number 


SS cug 010 


Test case group 


SIP-SIP/Service/CUG 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


([Network A] SE 17 AND SE 47 AND SE 58) AND ([Network B] SE 17 AND SE 
47 AND SE 58) 


Test purpose 


SIP-I/ISUP interworking. CUG call with outgoing access not allowed (both 
user in the same CUG). 

User A in a CUG is located in the PSTN part of Network A and ISUP/BIGG 
interworking applies in Network A. User B is located in the PSTN/PLMN part and 
SIP-I - ISUP/BIGG interworking applies in the same GUG. Ensure that when user 
A is in a GUG 'outgoing access not allowed' calls user B in Network B. The call is 
successful. There is a Optional forward call indicator the GUG Gall Indicator 
Outgoing access not allowed present in the encapsulated lAM sent to 
Network B. 


Configuration 


• User in PSTN/PLMN part of Network A in a GUG outgoing access not 
allowed 

User in PSTN/PLMN part of Network B in a GUG 

• User A and User B are in the same GUG 


SIP Parameter 


INVITE 

Gontent-Type: multipart/mixed;boundary=[any boundary name] 

--[any boundary name] 

Gontent-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

lAM 

Optional Forward call indicator 

GUG Gall Indicator 

Outgoing access not allowed 
CUG interlock code 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
4- 180 Ringing 


Comments 


User A in the PSTN part of Network A calls user B in the PST/PLMN part of 

Network B 

Check: Is an lAM encapsulated in the INVITE request sent from Network A to 

Network B? 
Check: Is the Optional forward call indicator present, the GUG Gall Indicator is 

set to 'Outgoing access not allowed'? 
Check: Is the GUG interlock code parameter present in the encapsulated 

lAM? 
Check: Is the call setup successful? 
Repeat this test in reverse direction. 
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Test case number 


SS cug 011 


Test case group 


SIP-SIP/Service/CUG 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


([Network A] SE 17 AND SE 47 AND SE 58) AND ([Network B] SE 17 AND SE 
47 AND SE 58) 


Test purpose 


SIP-I/ISUP interworking. CUG call to a CUG user incoming access not 
allowed (both user in the same CUG). 

User A in a CUG is located in the PSTN part of Network A and ISUP/BICC 
interworking applies in Network A. User B is located in the PSTN/PLMN part and 
SIP-I - ISUP/BICC interworking applies in the same CUG. Ensure that when user 
A is in a CUG 'outgoing access not allowed' calls CUG user B in Network B. The 
call is successful. There is a Optional forward call indicator the CUG Call 
Indicator Outgoing access not allowed present in the encapsulated lAM sent 
to Network B. 


Configuration 


• User in PSTN/PLMN part of Network A in a CUG outgoing access not 
allowed 

• User in PSTN/PLMN part of Network B in a CUG incoming access not 
allowed 

• User A and User B are in the same CUG 


SIP Parameter 


INVITE 

Content-Type: multipart/mixed;boundary=[any boundary name] 

--[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

lAM 

Optional Forward call indicator 

CUG Call Indicator 

Outgoing access not allowed 
CUG interlock code 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 180 Ringing 


Comments 


User A in the PSTN/PLMN part of Network A calls user B in Network B 

User B in the PSTN/PLMN part of Network B. 

Check: Is an lAM encapsulated in the INVITE request sent from Network A to 

Network B? 
Check: Is the Optional forward call indicator present, the CUG Call Indicator is 

set to 'Outgoing access not allowed'? 
Check: Is the CUG interlock code parameter present in the encapsulated 

lAM? 
Check: Is the call setup successful? 
Repeat this test in reverse direction. 
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Test case number 


SS cug 012 


Test case group 


SIP-SIP/Service/CUG 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


([Network A] SE 17 AND SE 47 AND SE 58) AND ([Network B] SE 17 AND SE 
47 AND SE 58) 


Test purpose 


SIP-I/ISUP interworking. CUG call to a CUG user incoming access not 
allowed (both user in different CUG). 

User A in a CUG is located in the PSTN part of Network A and ISUP/BICC 
interworking applies in Network A. User B is located in the PSTN/PLMN part and 
SIP-I - ISUP/BICC interworking applies in different CUG. Ensure that when user 
A is in a CUG 'outgoing access not allowed' calls CUG user B in Network B. 
There is a Optional forward call indicator the CUG Call Indicator Outgoing 
access not allowed present in the encapsulated lAM sent to Network B. The 
call is rejected with a 500 (Server Internal error) final response. A ISUP/BICC 
REL is encapsulated and the Cause value is set to '87'. 


Configuration 


• User in PSTN/PLMN part of Network A in a CUG outgoing access not 
allowed 

• User in PSTN/PLMN part of Network B in a CUG incoming access not 
allowed 

• User A and User B are in different CUG 


SIP Parameter 


INVITE 

Content-Type: multipart/nnixed;boundary=[any boundary name] 

--[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

lAM 

Optional Forward call indicator 

CUG Call Indicator 

Outgoing access not allowed 
CUG interlock code 

--[any boundary name]- 

500 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

REL 

Cause indicators 

Cause value 
87 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 500 Server Internal error(REL) 

ACK ^ 


Comments 


User A in the PSTN/PLMN part of Network A calls user B in Network B 

User B in the PSTN/PLMN part of Network B. 

Check: Is an lAM encapsulated in the INVITE request sent from Network A to 

Network B? 
Check: Is the Optional forward call indicator present, the CUG Call Indicator is 

set to 'Outgoing access not allowed'? 
Check: Is the CUG interlock code parameter present in the encapsulated 

lAM? 
Check: Is the call rejected with a 500 final response and a ISUP/BICC REL is 

encapsulated and the cause value is set to 87? 
Repeat this test in reverse direction. 
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Test case number 


SS cug 013 


Test case group 


SIP-SIP/Service/CUG 


Reference 


7.1/[241 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 58 


Test purpose 


SIP-I/ISUP interworking. Call to a CUG user incoming access not allowed. 

User A is located in Network A. User B in a CUG Incoming access not allowed is 
located in the PSTN/PLMN part and SIP-I - ISUP/BIGG interworking applies. 
Ensure that when user A calls user B in Network B. The call is rejected with a 
500 (Server Internal error) final response. A ISUP/BIGG REL is encapsulated 
and the Cause value is set to '87'. 


Configuration 


• User in PSTN/PLMN part of Network B in a GUG incoming access not 
allowed 


SIP Parameter 


500 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

REL 

Cause indicators 

Cause value 
87 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 500 Server Internal error(REL) 

ACK ^ 


Comments 


User A in Network A calls user B in Network B 

User B in the PSTN/PLMN part of Network B. 

Check: Is the call rejected with a 500 final response and a ISUP/BIGG REL is 

encapsulated and the cause value is set to 87? 
Repeat this test in reverse direction. 



Test case number 


SS cug 014 


Test case group 


SIP-SIP/Service/CUG 


Reference 


7.1/f241 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 58 


Test purpose 


SIP-I/ISUP interworking. Call to a CUG user incoming access allowed. 

User A is located in Network A. User B is located in the PSTN/PLMN part and 
SIP-I - ISUP/BIGG interworking applied. Ensure that when user A calls CUG user 
B Incoming access allowed in Network B. The call is successful. 


Configuration 


• User in PSTN/PLMN part of Network B in a CUG incoming access allowed 


SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 180 Ringing 


Comments 


User A in Network A calls user B in Network B 
User B in the PSTN/PLMN part of Network B. 
Check: Is the call setup successful? 
Repeat this test in reverse direction. 
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7.1.5.10 Communication Waiting (CW) 



Test case number 


SS CW 001 


Test case group 


SIP-SIP/Service/CW 


Reference 


4.5.5.2/[15] 


SELECTION EXPRESSION 


SE35 


Test purpose 


Call Waiting indication in 180 response. 

User A is located in network A, user B is located in network B and subscribed to 

the communication Waiting service. 

Ensure that when user A calls user B, user A receives the 'communication 

Waiting indication' in the 180 Ringing provisional response if the user B is NDUB 

orUDUB. 


Configuration 


User B subscribed to the CW service 


SIP Parameter 


180: 

Alert-Info: <urn:alert:service:call-waiting> 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 180 Ringing 

Apply post test routine 


Comments 


Check: Is an Alert-Info header present in the 180 Ringing Response and is the 

value set to '<urn:alert:service:call-waiting>'? 
Repeat this test in reverse direction. 



Test case number 


SS CW 002 


Test case group 


SIP-SIP/Service/CW 


Reference 


4.5.5.2/[15] 


SELECTION EXPRESSION 


SE35ANDSE36 


Test purpose 


Call rejected after timeout TAS-CW. 

User A is located in network A, user B is located in network B and subscribed to 
the communication Waiting service. 

Ensure that when user A calls user B, user A receives the 'communication 
Waiting indication' in the 180 Ringing provisional response if the user B is NDUB 
or UDUB. After timeout TAS-CW network B sends a 480 (Temporarily 
unavailable) response toward user A and the Reason header field is set to '19'. 


Configuration 




SIP Parameter 


180: 

Alert-Info: <urn:alert:service:call-waiting> 

480: 

Reason: Q.850 ;cause=19 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 180 Ringing 

Timeout TAS-CW 
^ 480 (Temporarily unavailable) 

ACK ^ 


Comments 


Check: Is an Alert-Info header present in the 180 Ringing Response and is the 

value set to '<urn:alert:service:call-waiting>'? 
Check: Is a Reason header present in the 480 Response and is the protocol is 

set to 'Q.850' and the cause parameter set to '19'? 
Repeat this test in reverse direction. 
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Test case number 


SS cw 003 


Test case group 


SIP-SIP/Service/CW 


Reference 


6.5/[241 


SELECTION EXPRESSION 


[Network B] SE 17 AND SE 47 AND SE 59 


Test purpose 


SIP-I support. Call Waiting indication in 180 with encapsulated ACM. 

User A is located in network A, user B is located in the PSTN/PLMN part of 
network B and subscribed to the Call Waiting service. 
Ensure that when user A calls user B, an encapsulated ISUP/BIGG ACM 
Generic notification 'call is a waiting call' is present in the 180 Ringing provisional 
response if the user B is NDUB. 


Configuration 


User B subscribed to the CW service 


SIP Parameter 


180 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

ACM 

Backward call indicator 

Called party's status indicator 
subscriber free 
Generic notification 

Notification indicator 
call is a waiting call 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 180 Ringing 

Apply post test routine 


Comments 


Check: Is an ISUP/BICC ACM present in the 180 provisional response and 

the Generic notification is set to 'call is a waiting cal'? 
Repeat this test in reverse direction. 



Test case number 


SS cw 004 


Test case group 


SIP-SIP/Service/CW 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 59 


Test purpose 


SIP-I support. Call Waiting indication in 180 with encapsulated CPG. 

User A is located in network A, user B is located in the PSTN/PLMN part of 
network B and subscribed to the Call Waiting service. 

Ensure that when user A calls user B, an encapsulated ISUP/BICC CPG Generic 
notification 'call is a waiting call' is present in the 180 Ringing provisional 
response if the user B is NDUB. 


Configuration 


User B subscribed to the CW service 


SIP Parameter 


180 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

CPG 

Event information 

Event indicator 
ALERTING 
Generic notification 

Notification indicator 
call is a waiting call 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 1 83 Session Progress (ACM) 
^ 180 Ringing (CPG) 
Apply post test routine 


Comments 


Check: Is an ISUP/BICC CPG present in the 180 provisional response and the 

Generic notification is set to 'call is a waiting cal'? 
Repeat this test in reverse direction. 
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7.1 .5.1 1 Explicit Communication Transfer (ECT) 



Test case number 


SS ect 001 


Test case group 


SIP-SIP/Service/EGT 


Reference 


4.5.2/[11] 


SELECTION EXPRESSION 


[Network A] SE 37 AND [Network A] SE 1 1 AND [Network A] SE 49 


Test purpose 


Blind/assured transfer using the REFER method. 

User A is located in network A, user B and user are located in network B. User 
A invokes EOT to transfer a session with user B to user 0. 

• Ensure that a REFER request is sent from network A to network B in the 
dialogue with user B. The URI in the Refer-To header is set to the 
address of the EOT AS in network A and the method parameter is set to 
'INVITE'. 

• Ensure that an INVITE request is sent from network B to network A and 
the Request URI is set to the address of the EOT AS in network A. 

• Ensure that an INVITE request is sent from network A to network B and 
the Request URI is set to the address of user 0. 


Configuration 




SIP Parameter 


REFER: Request URI address of user B 

Refer-To: <URI of EGT-AS>; method=invite 

INVITE1 Request URI address of ECT-AS 

INVITE2: Request URI address of user C 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 
A confirmed session is established between user A and user B 
A confirmed session is established between user A and user C 
User A invokes ECT to transfer the session to user C 
REFER ^ 
4- 202 Accepted 
^ NOTIFY (100) 

200 OK NOTIFY ^ 

CASE Blind transfer 

BYE (A-B) ^ 
^ 200 OK BYE 

^ INVITE1 (ECT-AS) 

INVITE2 (user C) ^ 

^ 200 OK INVITE 

ACK ^ 
200 OK INVITE ^ 

^ ACK 

^ NOTIFY (200) 

200 OK NOTIFY ^ 

CASE Assured transfer 

BYE (A-B) ^ 
^ 200 OK BYE 

Apply post test routine 
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Comments 


Check: Is a REFER request is sent network B, the Refer-To header is set to 

the URI of the ECT-AS in network A and a method parameter is 

present set to 'INVITE'? 
Check: Is a NOTIFY request sent to network A containing sipfrag body set to 

'SIP/2.0 100 Trying' and if Blind transfer is applicable the session from 

user A to user B is terminated by user A? 
Check: Is an INVITE request sent to network A the Request line is set to the 

address of the ECT-AS in network A? 
Check: Is an INVITE request is sent to network B the Request is set to the 

address of user 0? 
Check: When the session from user B to user C is confirmed a NOTIFY 

request is sent to network A containing sipfrag body set to 'SIP/2.0 

200 OK' and if Assured transfer is applicable the session from user A 

to user B is terminated by user A? 
Check: Ensure the property of speech between user B and user C. 
Repeat this test in reverse direction. 
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Test case number 


SS act 002 


Test case group 


SIP-SIP/Service/EGT 


Reference 


4.5.2/f11] 


SELECTION EXPRESSION 


[Network A] SE37 AND [Network A] SE 11 AND [Network A] SE 50 


Test purpose 


Consultative transfer using the REFER method. 

User A is located in network A, user B and user are located in network B. User 
A invokes EOT to transfer a session with user B to user 0. 

• Ensure that a REFER request is sent from network A to network B in the 
dialogue with user B. The URI in the Refer-To header is set to the 
address of the ECT AS in network A and the method parameter is set to 
'INVITE'. 

• Ensure that an INVITE request is sent from network B to network A and 
the Request URI is set to the address of the ECT AS in network A. 

• Ensure that an INVITE request is sent from network A to network B and 
the Request URI is set to the address of user C and a Replaces header 
is present containing the session identifiers of the session A - C. 


Configuration 




SIP Parameter 


REFER:Request URI address of user B 

Refer-To: <URI of ECT-AS>; method=invite 

INVITE1 Request URI address of ECT-AS 

INVITE2: Request URI address of user C 
Require: replaces 
Replaces: <session A-C> 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 
A confirmed session is established between user A and user B 
A confirmed session is established between user A and user C 
User A invokes ECT to transfer the session to user C 
REFER ^ 
^ 202 Accepted 
^ NOTIFY (100) 

200 OK NOTIFY ^ 

^ INVITE1 (ECT-AS) 

INVITE2 (user C) ^ 

^ 200 OK INVITE 

ACK ^ 
200 OK INVITE ^ 

^ ACK 

^ NOTIFY (200) 

200 OK NOTIFY ^ 

BYE (A-B) ^ 
^ 200 OK BYE 

^ BYE (A-C) 

200 OK BYE ^ 
Apply post test routine 


Comments 


Check: Is a REFER request is sent network B, the Refer-To header is set to 

the URI of the ECT-AS in network A and a method parameter is 

present set to 'INVITE'? 
Check: Is an INVITE request sent to network A the Request line is set to the 

address of the ECT-AS in network A? 
Check: Is an INVITE request is sent to network B the Request is set to the 

address of user C and a Replaces header is present contains the 

session identifiers of the session A-C? 
Check: Is the session A - B and the session A - C terminated? 
Check: Ensure the property of speech between user B and user C. 
Repeat this test in reverse direction. 
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Test case number 


SS act 003 


Test case group 


SIP-SIP/Service/EGT 


Reference 


4.5.2/[11], 4.7.2.9.7/[20] 


SELECTION EXPRESSION 


[Network A] SE37 AND NOT [Network A] SE 12 AND [Network A] SE 49 


Test purpose 


Blind/assured transfer using the 3pcc method. 

User A is located in network A, user B an user C are located in network B User A 
invokes ECT to transfer a session with user B to user C. 

• Ensure that the network A establishes a session to user C. 

• Ensure that the network A sends a relNVITE to update the session 
between user A and user B (SDP: IP address, port and codec). 


Configuration 




SIP Parameter 


INVITE1 Request URI address of user C 

INVITE2: Request URI address of user B 
SDP 

c=IN IP4/6 [new IP address] 

m=audio [new port] RTP/AVP [new codec list] 

a=[new attributes] 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

A confirmed session is established between user A and user B 

User A invokes ECT to transfer the session to user C 

INVITE1 (user C) ^ 
^ 180 Ringing 
^ 200 OK INVITE 

ACK ^ 

INVITE2 (user B) ^ 
^ 200 OK INVITE 

ACK ^ 
Apply post test routine 


Comments 


Check: Is an initial INVITE is sent from network A to user to establish a 

dialogue between network A and user 0? 
Check: Is a relNVITE is sent from network A to user B update the session 

parameter in the SDP? 
Repeat this test in reverse direction. 
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Test case number 


SS act 004 


Test case group 


SIP-SIP/Service/EGT 


Reference 


4.5.2/[11], 4.7.2.9.7/[20] 


SELECTION EXPRESSION 


[Network A] SE37 AND [Network A] SE 12 AND [Network A] SE 50 


Test purpose 


Consultative transfer using the 3pcc method. 

User A is located in network A, user B and user are located in network B 
User A invokes EOT to transfer a session with user B to user 0. 

• Ensure that the network A sends a relNVITE to update the session 
between user A and user B (SDP: IP address, port and codec). 

• Ensure that the network A sends a relNVITE to update the session 
between user A and user (SDP: IP address, port and codec). 


Configuration 




SIP Parameter 


INVITE1 : Request URI address of user C 
SDP 

c=IN IP4/6 [new IP address] 

m=audio [new port] RTP/AVP [new codec list] 

a=[new attributes] 

rNVITE2: Request URI address of user B 
SDP 

c=IN IP4/6 [new IP address] 

m=audio [new port] RTP/AVP [new codec list] 

a=[new attributes] 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

A confirmed session is established between user A and user B 

A confirmed session is established between user A and user C 

User A invokes ECT to transfer the session to user C 

INVITE1 (user B) ^ 

^ 200 OK INVITE 

ACK ^ 

INVITE2 (user C) ^ 
^ 200 OK INVITE 

ACK ^ 
Apply post test routine 


Comments 


Check: Is a relNVITE is sent from network A to user B update the session 

parameter in the SDP. 
Check: Is a relNVITE is sent from network A to user C update the session 

parameter in the SDP. 
Repeat this test in reverse direction. 
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Test case number 


SS ect 005 


Test case group 


SIP-SIP/Service/ECT 


Reference 


5.4.3.2/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 60 


Test purpose 


SIP-I support. Call Transfer invoked in active state, call was previous on 
HOLD. 

BICC/ISUP - SIP-I interworking applies in the originating network User A and C 
are located in network A and user B is located in network B. 
Ensure that an User A can successfully invoke the ECT supplementary service 
and transfer the call with User B to User C in active state. 


Configuration 


User A is subscribed to the Explicit Call Transfer supplementary service 


SIP Parameter 


INVITE 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 
Content-Type: application/sdp 
a=sendrecv 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

FAC 

Generic Notification 
Call transfer active 

Call transfer number 
-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

A confirmed session is established between user A and user B and set on hold 

User A invokes ECT to transfer the session to user C 

INFO (LOP request) ^ 
^ 200 OK INFO 
^ INFO (LOP response) 

200 OK INFO ^ 
CASE A 


CASEB 


fJVITE (sendrecv; FAC) ^ 
^ 200 OK INVITE 

ACK ^ 

INFO (FAC) ^ 
^ 200 OK INFO 

INVITE (sendrecv) ^ 
^ 200 OK INVITE 

ACK ^ 
Apply post test routine 


Comments 


A session from User A to User B is already established 

User A sets the User B on hold 

User A invokes the ECT service 

Check: Is (optional) an INFO request is sent from Network A to Network B 

and an ISUP LOP message is present the Loop prevention indicator 

set to request? 
Check: Is (optional) an INFO request is sent from Network A to Network B 

and an ISUP LOP message is present the Loop prevention indicator 

set to response? 
Check: Is (CASE A) an INVITE request sent and an ISUP FAC message is 

present containing a Generic notification indicator is set to 'Call 

transfer active' and in addition the media stream is set to 

'sendrecv'? 
Check: Is (CASE B) an INFO request sent and an ISUP FAC message is 

present containing a Generic notification indicator is set to 'Call 

transfer active'? In addition is an INVITE request sent and the media 

stream is set to 'sendrecv' to resume the held session? 
NOTE: The content of the FAC in the INVITE request is Equal to the content 

of the FAC in the INFO request. 
Repeat this test in reverse direction. 
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Test case number 


SS ect 006 


Test case group 


SIP-SIP/Service/ECT 


Reference 


5.4.3.2/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 60 


Test purpose 


SIP-I support. Call Transfer invoked in alerting state, call was previous on 
HOLD. 

BICC/ISUP - SIP-I interworking applies in the originating network User A and C 
are located in network A and user B is located in network B. 
Ensure that an User A can successfully invoke the ECT supplementary service 
and transfer the call with User B to User C in alerting state. 


Configuration 


User A is subscribed to the Explicit Call Transfer supplementary service 


SIP Parameter 


INVITE 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 
Content-Type: application/sdp 
a=sendrecv 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

FAC 

Generic Notification 
Call transfer alerting 

Call transfer number 
-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

A confirmed session is established between user A and user B and set on hold 

User A invokes ECT to transfer the session to user C 

INFO (LOP request) ^ 
^ 200 OK INFO 
^ INFO (LOP response) 

200 OK INFO ^ 
CASE A 


CASEB 


fJVITE (sendrecv; FAC) ^ 
^ 200 OK INVITE 

ACK ^ 

INFO (FAC) ^ 
^ 200 OK INFO 

INVITE (sendrecv) ^ 
^ 200 OK INVITE 

ACK ^ 
Apply post test routine 


Comments 


A session from User A to User B is already established 

User A sets the User B on hold 

A session from User A to User C is already established 

User A invokes the ECT service 

Check: Is (optional) an INFO request is sent from Network A to Network B 

and an ISUP LOP message is present the Loop prevention indicator 

set to request? 
Check: Is (optional) an INFO request is sent from Network A to Network B 

and an ISUP LOP message is present the Loop prevention indicator 

set to response? 
Check: Is (CASE A) an INVITE request sent and an ISUP FAC message is 

present containing a Generic notification indicator is set to 'Call 

transfer alerting' and in addition the media stream is set to 'sendrecv'? 
Check: Is (CASE B) an INFO request sent and an ISUP FAC message is 

present containing a Generic notification indicator is set to 'Call 

transfer alerting'? In addition is an INVITE request sent and the media 

stream is set to 'sendrecv' to resume the held session? 
NOTE: The content of the FAC in the INVITE request is Equal to the content 

of the FAC in the INFO request. 
Repeat this test in reverse direction. 
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Test case number 


SS ect 007 


Test case group 


SIP-SIP/Service/ECT 


Reference 


5.4.3.2/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 60 


Test purpose 


SIP-I support. Call Transfer invoked in active state. 

BICC/ISUP - SIP-I interworking applies in the originating network Users A and B 
are located in network A and User C is located in network B. 
Ensure that an User A can successfully invoke the ECT supplementary service 
and transfer the call with User B to User in active state. 


Configuration 


User A is subscribed to the Explicit Gall Transfer supplementary service 


SIP Parameter 


INFO 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
FAC 

Generic Notification 

Call transfer active 
Call transfer number 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

A confirmed session is established between user A and user C 

User A invokes ECT to transfer the session to user C 

INFO (LOP request) ^ 
^ 200 OK INFO 
^ INFO (LOP response) 

200 OK INFO ^ 

INFO (FAC) ^ 
^ 200 OK INFO 

Apply post test routine 


Comments 


A session from User A to User B is already established 

User A sets the User B on hold 

A session from User A to User C is already established 

User A invokes the ECT service 

Check: Is (optional) an INFO request is sent from Network A to Network B 

and an ISUP LOP message is present the Loop prevention indicator 

set to request? 
Check: Is (optional) an INFO request is sent from Network A to Network B 

and an ISUP LOP message is present the Loop prevention indicator 

set to response? 
Check: Is (CASE B) an INFO request sent and an ISUP FAC message is 

present containing a Generic notification indicator is set to 'Call 

transfer active'? 
NOTE: The content of the FAC in the INVITE request is Equal to the content 

of the FAC in the INFO request. 
Repeat this test in reverse direction. 
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Test case number 


SS ect 008 


Test case group 


SIP-SIP/Service/ECT 


Reference 


5.4.3.2/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 60 


Test purpose 


SIP-I support. Call Transfer invoked in alerting state. 

BICC/ISUP - SIP-I interworking applies in the originating network User A and B 
are located in network A and user C is located in network B. 
Ensure that an User A can successfully invoke the ECT supplementary service 
and transfer the call with User B to User in alerting state. 


Configuration 


User A is subscribed to the Explicit Gall Transfer supplementary service 


SIP Parameter 


INFO 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
CPG 

Generic Notification 

Call transfer alerting 
Call transfer number 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

A session in the early dialogue is established between user A and user C 

User A invokes ECT to transfer the session to user C 

INFO (LOP request) ^ 
^ 200 OK INFO 
^ INFO (LOP response) 

200 OK INFO ^ 

INFO (CPG) ^ 
^ 200 OK INFO 

Apply post test routine 


Comments 


A session from User A to User B is already established 

User A sets the User B on hold 

A session from User A to User C is already established 

User A invokes the ECT service 

Check: Is (optional) an INFO request is sent from Network A to Network B 

and an ISUP LOP message is present the Loop prevention indicator 

set to request? 
Check: Is (optional) an INFO request is sent from Network A to Network B 

and an ISUP LOP message is present the Loop prevention indicator 

set to response? 
Check: Is (CASE B) an INFO request sent and an ISUP CPG message is 

present containing a Generic notification indicator is set to 'Call 

transfer alerting'? 
NOTE: The content of the FAC in the INVITE request is Equal to the content 

of the FAC in the INFO request. 
Repeat this test in reverse direction. 
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7.1.5.12 



Malicious Communication Identification (MCID) 



Test case number 


SS mcid 001 


Test case group 


SIP-SIP/Service/MGID 


Reference 


4.5.2.5/[18] 


SELECTION EXPRESSION 


SE38 


Test purpose 


Network B sends a MCID request, no response. 

User A is located in network A, user B is located in network B and subscribed to 
the Malicious Communication Identification service. 

When user A call user B and no originating identification is present in the INVITE 
request, the network B sends an INFO request to network A requesting the 
originating identity. After timeout of timer TO-ID the network B sends the 180 
Ringing response. 


Configuration 


User B is subscribed to the MCID service 


SIP Parameter 


INFO: 

<...:mcid > 

<...:request> 

<. . . :McidRequestlndicator>01 </. . . :McidRequestlndicator> 
<. . . :Holdinglndicator >...</... :Holdinglndicator> 
</...:request> 
</...:mcid> 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ INFO 

200 OK INFO ^ 
Timeout Tq-id 
^ 180 Ringing 

Apply post test routine 


Comments 


Check: Is an INFO request sent to network A? 
Check: Is the McidRequestlndicator element set to ,01 '? 
Check: is a 200 OK INFO response sent to network B? 
Repeat this test in reverse direction. 
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Test case number 


SS mcid 002 


Test case group 


SIP-SIP/Service/MCID 


Reference 


4.5.2.5/f18l 


SELECTION EXPRESSION 


SE 38 AND SE 47 


Test purpose 


Network B sends a MCID request, MCID response. 

PSTN user A is located in network A, user B is located in network B and 
subscribed to the Malicious Communication Identification service. 
When user A call user B and no originating identification is present in the INVITE 
request, the network B sends an INFO request to network B requesting the 
originating identity. After receipt of an INFO request from network A the network 
B sends the 180 Ringing response. 


Configuration 


User B subscribed to the MOID service 

User A is a ISDN or POTS user in the PSTN of network A 


SIP Parameter 


INFO: 

<...:mcid > 

<...:request> 

<. . . :McidRequestlndicator>01 </. . . :McidRequestlndicator> 
<. . . :Holdinglndicator >. . .</. . . :Holdinglndicator> 
</...:request> 
</...:mcid> 

<...:mcid > 

<...:response> 

<. . . :McidResponselndicator>01 </. . . :McidResponselndicator> 
<. . . :HoldingProvidedlndicator>. . .</. . . :HoldingProvidedlndicator> 
<. . . :OrigPartyldentity>any URI</. . . :OrigPartyldentity> 
<. . . :OrigPartyPresentationRestriction> 

true/false 
</. . . :OrigPartyPresentationRestriction> 
</...:response> 
</...:mcid> 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ INFO 

200 OK INFO ^ 

^ 200 OK INFO 
^ 180 Ringing 

Apply post test routine 


Comments 


Check: Is an INFO request sent to network A? 

Check: Is the McidRequestlndicator element set to ,01 '? 

Check: Is a 200 OK INFO response sent to network B? 

Check: Is an INFO request sent to network B? 

Check: Is the McidResponselndicator element set to ,01 '? 

Check: Is the OrigPartyldentity element present in the response element? 

Check: Is a 200 OK INFO response sent to network A? 

A INFO request containing a mcid response element sent by the MGCF in 

network A is optional. 

Repeat this test in reverse direction. 
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Test case number 


SS mcid 003 


Test case group 


SIP-SIP/Service/MGID 


Reference 


5.4.3.2/[241 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 61 


Test purpose 


SIP-I support. Network B sends a MCID request, no response. 

User A is located in network A, user B is located in the PSTN/PLMN part of 
network B and subscribed to the Malicious Gall Identification service. 
When user A call user B and no originating identification is present in the INVITE 
request, the network B sends an INFO request to network A and an ISUP/BIGG 
IDR message is present the MGID request indicator is set to 'MGID requested' 
requesting the originating identity. After timeout of timer (ISUP) T39 the network 
B sends the 180 Ringing response. 


Configuration 


User B is subscribed to the MGID service 


SIP Parameter 


INFO: 

Gontent-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

IDR 

MCID request indicators 

MGID request indicator 
MGID requested 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ INFO(IDR) 

200 OK INFO ^ 
Timeout Tq-id 
4- 180 Ringing 

Apply post test routine 


Comments 


Check: Is an INFO request sent to network A? 

Check: Is a ISUP/BIGG IDR message is present and the MGID request 

indicator is set to 'MGID requested'? 
Check: Is a 200 OK INFO response sent to network B? 
NOTE: Based on network policies the MGID request indicator can be set 

to'MGID not requested'. 
Repeat this test in reverse direction. 
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Test case number 


SS mcid 004 


Test case group 


SIP-SIP/Service/MCID 


Reference 


5.4.3.2/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 61 


Test purpose 


SIP-I support. Network B sends a MCID request, MCID response. 

PSTN user A is located in network A, user B is located in the PSTN/PLMN part 
of network B and SIP-I - ISUP/BICC interworking applies and User B is 
subscribed to the Malicious Call Identification service. 

When user A call user B and no originating identification is present in the INVITE 
request, the network B sends an INFO request to network B requesting the 
originating identity. After receipt of an INFO request from network A the network 
B sends the 180 Ringing response. 


Configuration 


User B subscribed to the MOID service 

User A is a ISDN or POTS user in the PSTN of network A 


SIP Parameter 


INFO: 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

IDR 

MCID request indicators 

MCID request indicator 
MCID requested 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

IRS 

MCID response indicators 

MCID response indicator 
MCID included 
Calling party number 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ INFO(IDR) 

200 OK INFO ^ 
INFO(IRS) ^ 
^ 200 OK INFO 
^ 180 Ringing 

Apply post test routine 


Comments 


Check: Is an INFO request sent to network A and a ISUP/BICC IDR is present 
and the MCID request indicator is set to 'MCID requested'? 

Check: Is a 200 OK INFO response sent to network B? 

Check: Is an INFO request sent to network B and a ISUP/BICC IRS is present 
and the MCID response indicator is set to 'MCID included'? 

Check: Is the Calling party number present in the attached ISUP/BICC IRS? 

Check: Is a 200 OK INFO response sent to network A? 

Repeat this test in reverse direction. 
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7.1.5.13 



Message Waiting Indication (MWI) 



Test case number 


SS mwi 001 


Test case group 


SIP-SIP/Service/MWI 


Reference 


4.7.2/[16] 


SELECTION EXPRESSION 


[Network A] SE 39 AND [Network B] SE 39 


Test purpose 


Initial subscription of a Voicemail box. 

The Voicemail owner is in network A, his Voicemail box is located in network B. 
Ensure that a Voicemail owner is able to activate his Voicemail box. 


Configuration 


Voicemail in network B 
Voicemail owner in network A 


SIP Parameter 


SUBCRIBE 

Event: message-summary 

Expires: [any value] 

Accept: application/simple-message-summary 

NOTIFY 

Subscription-State: active;expires=[any value] 
Event: message-summary 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

SUBCRIBE ^ 
^ 200 OK SUBSCRIBE 

^ NOTIFY 

200 OK NOTIFY ^ 
^ 200 OK BYE 

^ NOTIFY 

200 OK NOTIFY ^ 
Apply post test routine 


Comments 


Check: Is it possible for a user in network A to subscribe to a Voicemail box in 
network B? 

Check: Is the Event header in the SUBCRIBE set to 'message-summary'? 

Check: Is the Accept header in the SUBCRIBE set to 'application/simple- 
message-summary'? 

Check: Is the Event header in the NOTIFY is set to 'message-summary'? 

Repeat this test in reverse direction. 
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Test case number 


SS mwi 002 


Test case group 


SIP-SIP/Service/MWI 


Reference 


4.7.2/[16] 


SELECTION EXPRESSION 


[Network A] SE 39 AND [Network B] SE 39 


Test purpose 


A new entry in the Voicemail box is indicated to the owner. 

The Voicemail owner is in network A, his Voicemail box is located in network B. 
Ensure when a user calls user A and the call is not answered, the call is 
forwarded to the Voicemail box of user A in network B. Ensure that the user A is 
notified by message waiting indication that there is a new message present in his 
voicemail account. 


Configuration 


Voicemail in network B 
Voicemail owner in network A 


SIP Parameter 


NOTIFY 

Subscription-State: active;expires=[any value] 

Event: message-summary 

Content-Type: application/simple-message-summary 

Messages-Waiting: yes 

Message-Account: sip:userA@networkA (optional) 

Voice-Message: [any new value]/[any old value] (optional) 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 200 OK INVITE 

ACK ^ 

BYE ^ 
^ 200 OK BYE 

^ NOTIFY 

200 OK NOTIFY ^ 
Apply post test routine 


Comments 


Check: Is the Event header in the NOTIFY set to 'message-summary'? 
Check: Is the Content-Type header in the NOTIFY set to 'application/simple- 
message-summary'? 
Check: Contains the IVIIIVIE body the header 'IVIessages-Waiting' set to 'yes'? 
Check: Contains the IVIIIVIE body the optional header 'Message-Account'? 
Check: Contains the MIME body the optional header 'Voice-Message'? 
Repeat this test in reverse direction. 
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7.1 .5.14 Completion of Communications to Busy Subscriber (CCBS), Completion of 
Communications by No Reply (CCNR) 



Test case number 


88 cc 001 


Test case group 


8IP-8IP/8ervice/GG 


Reference 


4.5.4.3/[14] 


SELECTION EXPRESSION 


[Network A] 8E 40 AND [Network B] 8E 40 


Test purpose 


Indicating of CCBS possible. 

User A is located in network A and user B is located in network B. 

Ensure when user A calls user B and user B is busy, the network B sends an 

indication that GGB8 is possible in the 486 Busy Here final response. 


Configuration 




SIP Parameter 


486: 

Gall-Info: <sip:UE-B>;purpose=call-completion;m=B8 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 486 Busy Here 

ACK ^ 


Comments 


Check: The 486 final response contains the Gall-Info header. 

Check: The Gall-Info header contains the URI of user B as the monitor point in 

network B. 
Check: The Gall-Info header contains the purpose parameter set to 

'call-completion' and the m parameter set to 'B8'. 
Repeat this test in reverse direction. 



Test case number 


88 cc 002 


Test case group 


8IP-8IP/8ervice/GG 


Reference 


4.5.4.3/[14] 


SELECTION EXPRESSION 


[Network A] 8E 41 AND [Network B] 8E 41 


Test purpose 


Indicating of CCNR possible. 

User A is located in network A and user B is located in network B. 

Ensure when user A calls user B and user B is free, the network B sends an 

indication that GGNR is possible in the 180 Ringing provisional response. 


Configuration 




SIP Parameter 


180: 

Gall-Info: <sip:UE-B>;purpose=call-completion;m=NR 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 180 Ringing 

Apply post test routine 


Comments 


Check: The 180 provisional response contains the Gall-Info header. 

Check: The Gall-Info header contains the URI of user B as the monitor point in 

network B. 
Check: The Gall-Info header contains the purpose parameter set to 

'call-completion' and the m parameter set to 'NR'. 
Repeat this test in reverse direction. 
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Test case number 


SS cc 003 


Test case group 


SIP-SIP/Service/GG 


Reference 


4.5.4.2/[14l 


SELECTION EXPRESSION 


([Network A] SE 40 OR [Network A] SE 41) AND ([Network B] SE 40 OR 
[Network B]SE 41) 


Test purpose 


Invocation of CCBS or CCNR. 

User A is located in network A and user B is located in network B. 

• Ensure when user A call user B and user B is busy, the indication that 
CCBS is possible is sent to the network A. when user A invokes CCBS, 
a SUBSCRIBE request is sent to the network B, the Event header is set 
to 'call-completion' and the m parameter in the Request line is set to 
'BS'. 

• Ensure when user A call user B and user B is free, the indication that 
CCNR is possible is sent to the network A. when user A invokes CCNR, 
a SUBSCRIBE request is sent to the network B, the Event header is set 
to 'call-completion' and the m parameter in the Request line is set to 
'NR'. 

Ensure that the network B sends a NOTIFY request to network A to confirm that 
the request is in the Call completion queue at the terminating Application Server. 


Configuration 




SIP Parameter 


SUBSRIBE sip:B-AS;m=BS or m=NR 
From:<UE-A> 
To:<UE-B> 
Contact:<A-AS> 
Event:call-completion 

NOTIFY sip:A-AS 

Event:call-completion 

Content-Type: application/call-completion 

state: queued 

service-retention 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 
An indication whether CCBS or CCNR is possible is sent by network B 

SUBSCRIBE ^ 
^ 202 Accepted 

^ NOTIFY 

200 OK NOTIFY ^ 
Apply post test routine 


Comments 


Check: Is a SUBCRIBE request is sent to network B? 

Check: Is the m parameter in the Request URI is set to 'BS' in case of CCBS 

request or set to 'NR' in case of CCNR? 
Check: Is a NOTIFY request is sent to network A and the Event header is set 

to 'call-completion' and the state header in the message body is set to 

'queued". 
Repeat this test in reverse direction. 
NOTE: The service-retention header in the NOTIFY body is a network option. 



ETSI 



206 



ETSI TS 101 585 VI .1.2 (2012-09) 



Test case number 


SS cc 004 


Test case group 


SIP-SIP/Service/GG 


Reference 


4.5.4.3/[14l 


SELECTION EXPRESSION 


([Network A] SE 40 OR [Network A] SE 41) AND ([Network B] SE 40 OR 
[Network B]SE 41) 


Test purpose 


Invocation of CCBS or CCNR unsuccessful; short term denial 

User A is located in network A and user B is located in network B. 

Ensure that user A invokes a CCBS or CCNR request to network B and the 
network B is currently unable to process the request (e.g. the B-queue is full), a 
480 Temporarily Unavailable final response is sent. 


Configuration 




SIP Parameter 


SUBSRIBE sip:B-AS;m=BS or m=NR 
From:<UE-A> 
To:<UE-B> 
Contact:<A-AS> 
Event:call-completion 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 
An indication whether CCBS or CCNR is possible is sent by network B 

SUBSCRIBE ^ 
^ 480 (Temporarily Unavailable) 


Comments 


Check: Is a SUBCRIBE request is sent to network B? 

Check: Is the m parameter in the Request URI is set to 'BS' in case of CCBS 

request or set to 'NR' in case of CCNR? 
Check: Is a 480 Temporarily Unavailable sent from network B indicates the 

CCBS or CCNR request is unsuccessful e.g. CC queue is full? 
Repeat this test in reverse direction. 
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Test case number 


SS cc 005 


Test case group 


SIP-SIP/Service/CC 


Reference 


4.5.4.3/f14l 


SELECTION EXPRESSION 


([Network A] SE 40 OR [Network A] SE 41) AND ([Network B] SE 40 OR 
[Network B]SE 41) 


Test purpose 


Successful CC operation 

User A is located in network A and user B is located in network B. User A has 
successfully invoked a CCBS or CCNR request. 

• Ensure when the user B becomes available for CC recall, the CC recall 
procedure is started. The network B sends a NOTIFY request to network A 
and a state header is present in the message body set to 'ready'. 

• Ensure that the recall from user A to user B is successful. 

• Ensure that a CC revocation notification is dent to network A to indicate the 
subscription is terminated; the reason header is set to 'noresource'. 


Configuration 




SIP Parameter 


NOTIFY sip:0-AS 

Event:call-completion 
Content-Type: application/call-completion 
state: ready 

NOTIFY sip:0-AS 

Event:call-completion 

Subscription-State: terminated; reason=noresource 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 
A CCBS or CCNR request was already successful 

^ NOTIFY 

200 OK NOTIFY ^ 

INVITE ^ 
4- 180 Ringing 

^ NOTIFY 

200 OK NOTIFY ^ 

^ 200 OK INVITE 

ACK ^ 
Apply post test routine 


Comments 


Check: Is a NOTIFY request is sent to network A and the Event header is set 
to 'call-completion' and the state header in the message body is set to 
'ready'? 

Check: Is the recall from user A to user B is successful? 

Check: Is the CC revocation is performed after the 1 80 Ringing or the 200 OK 
INVITE was sent to user A? 

Repeat this test in reverse direction. 
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Test case number 


SS cc 006 


Test case group 


SIP-SIP/Service/CC 


Reference 


4.5.4.31/[14] 


SELECTION EXPRESSION 


([Network A] SE 40 OR [Network A] SE 41) AND ([Network B] SE 40 OR 
[Network B]SE 41) 


Test purpose 


No CC call as result. 

User A is located in network A and user B is located in network B. User A has 

successfully invoked a CCBS or CCNR request. 

Ensure when no recall result is performed while CC-T9 is running (user A does 

not calls to user B) the network B sends a NOTIFY request to network A with an 

indication that the subscription is terminated, the reason header is set to 

'rejected'. 


Configuration 




SIP Parameter 


NOTIFY sip:0-AS 

Event:call-completion 
Content-Type: application/call-completion 
state: ready 

NOTIFY sip:0-AS 

Event:call-completion 

Subscription-State: terminated; reason=rejected 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

A CCBS or CCNR request was already successful 

User B is available for recall 

^ NOTIFY 

200 OK NOTIFY ^ 
CC-T9 expires 

^ NOTIFY 

200 OK NOTIFY ^ 


Comments 


Check: Is a NOTIFY request is sent to network A and the Event header is set 
to 'call-completion' and the state header in the message body is set to 
'ready'? 

User A does not perform the recall 

Check: Is the CC revocation is performed after timer CC-T9 expires? 

Repeat this test in reverse direction. 
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Test case number 


SS cc 007 


Test case group 


SIP-SIP/Service/CC 


Reference 


4.5.4.2/f14l 


SELECTION EXPRESSION 


([Network A] SE 40 OR [Network A] SE 41) AND ([Network B] SE 40 OR 
[Network B]SE 41) 


Test purpose 


User A is unavailable while CC recall is performed. 

User A is located in network A and user B is located in network B. User A has 
successfully invoked a CCBS or CCNR request. User B is available for CC-recall 
and network B sends a CC-recall notification to network A. 

• Ensure that network A sends PUBLISH request to suspend the recall 
procedure. 

• Ensure that network A sends PUBLISH request to resume the recall 
procedure if user A is available to complete the recall procedure. 

• Ensure the network B sends a NOTIFY request to indicate the CC-recall 
procedure. 


Configuration 




SIP Parameter 


NOTIFY sip:0-AS 

Event:call-completion 
Content-Type: application/call-completion 
state: ready 

PUBLISH sip B-AS 
To: SIP 2 
Event: presence 

Content-Type: application/pidf+xml 
<?xml version="1 .0" encoding="UTF-8"?> 
<presence 
<status> 
<basic>closed</basic> 

Publish sip b-as 

To: SIP 2 
Event: presence 

Content-Type: application/pidf+xml 
<?xml version="1.0" encoding="UTF-8"?> 
<presence 
<status> 
<basic>open</basic> 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

A CCBS or CCNR request was already successful 

User B is available for recall 

^ NOTIFY 

200 OK NOTIFY ^ 
User A is busy 

PUBLISH ^ 
^ 200 OK PUBLISH 

User A is no longer busy 

PUBLISH ^ 
^ 200 OK PUBLISH 

User B is available for recall 
^ NOTIFY 

200 OK NOTIFY ^ 
Apply post test routine 


Comments 
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Test case number 


SS cc 008 


Test case group 


SIP-SIP/Service/CC 


Reference 


6.11.2/[24] 


SELECTION EXPRESSION 


[Network B] SE 17 AND SE 47 


Test purpose 


SIP-I support: Indicating of CCBS possible. 

BICC/ISUP - SIP-I interworking applies in the terminating network and User A is 
located in network A and user B is located in network B. 
Ensure when user A calls user B and user B is busy, the network B sends a 486 
Busy Here final response and an encapsulated ISUP REL is present, the Cause 
value indicator is set to #17 or #34 and the CCBS possible indicator is set to 
'CCBS possible'. 


Configuration 




SIP Parameter 


486: 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

REL 

Cause value 

#17 or #34 
Diagnostics 

CCBS possible 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 486 Busy Here (REL) 

ACK ^ 


Comments 


Check: The 486 final response contains an encapsulated BICC/ISUP REL, the 
Cause value set to 17 or 34 and the Diagnostics set to 'CCBS 
possible'. 

Repeat this test in reverse direction. 



Test case number 


SS cc 009 


Test case group 


SIP-SIP/Service/CC 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B]SE 17 AND SE 47 


Test purpose 


SIP-I support: Indicating of CCNR possible. 

BICC/ISUP - SIP-I interworking applies in the terminating network User A is 
located in network A and user B is located in network B. 
Ensure when user A calls user B and user B is free, the network B sends a 1 80 
Ringing provisional response and an encapsulated ACM is present containing a 
CCNR possible indicator set to 'CCNR possible'. 


Configuration 




SIP Parameter 


180: 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

ACM 

CCNR possible indicator 
CCNR possible 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 180 Ringing (ACM) 
Apply post test routine 


Comments 


Check: The 180 provisional response contains an encapsulated ACM. 
Check: The CCNR possible indicator in the ACM is set to 'CCNR possible'. 
Repeat this test in reverse direction. 
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7.1 .6 Other PSTN services (SIP-I interworking) 



7.1.6.1 



User-to-User Signaling (UUS) 



Test case number 


88 UUS 001 


Test case group 


8IP-8IP/8IP-I/UU8 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


[Network A] 8E 1 7 AND 8E 47 AND 8E 63 


Test purpose 


SIP-I support: Indicating of User-to-User service 1 implicit in initial INVITE 
request. 

BICC/I8UP - 8IP-I interworking applies in the originating network User A is 
located in network A and user B is located in network B. 
Ensure when user A subscribed to the User-to-User service 1 implicit request 
calls user B an User-to-user Information parameter is present in the 
encapsulated lAM of the initial INVTE request. 


Configuration 


User A is subscribed to the User-to-User service 1 implicit request 


SIP Parameter 


INVITE: 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

lAM 

User-to-user Information 
User Information 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE (lAM) ^ 
Apply post test routine 


Comments 


Check: Is an I8UP/BICC lAM encapsulated in the initial INVITE request? 
Check: Is a User-to-user Information parameter present in the encapsulated 

I8UP/BICC lAM? 
Repeat this test in reverse direction. 
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Test case number 


SS uus 002 


Test case group 


SIP-SIP/SIP-I/UUS 


Reference 


7.1,6.5/[241 


SELECTION EXPRESSION 


([Network A] SE 1 7 AND SE 47) AND ([Network B] SE 1 7 AND SE 47) AND SE 
63 


Test purpose 


SIP-I support: Indicating of User-to-User service 1 implicit response in 180. 

BIGG/ISUP - SIP-I interworking applies in the originating and terminating network 
User A is located in network A and user B is located in network B. 
Ensure when user A subscribed to the User-to-User service 1 implicit request 
calls user B subscribed to User-to-User service 1 an User-to-user Information 
parameter is present in the encapsulated ACM of the 180 response. 


Configuration 


User A is subscribed to the User-to-User service 1 implicit request 


SIP Parameter 


INVITE: 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
lAM 

User-to-user Information 
User Information 

180 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
ACM 

User-to-user Information 
User Information 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE (lAM) ^ 
^ 180 Ringing (ACM) 
Apply post test routine 


Comments 


Check: Is an ISUP/BICC lAM encapsulated in the initial INVITE request? 
Check: Is a User-to-user Information parameter present in the encapsulated 

ISUP/BICC lAM? 
Check: Is an ISUP/BICC ACM encapsulated in the 1 80 response? 
Check: Is a User-to-user Information parameter present in the encapsulated 

ISUP/BICC ACM? 
Repeat this test in reverse direction. 
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Test case number 


SS uus 003 


Test case group 


SIP-SIP/SIP-I/UUS 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 63 


Test purpose 


SIP-I support: Indicating of User-to-User service 1 explicit in initial INVITE 
request. 

BICC/ISUP - SIP-I interworking applies in the originating network User A is 
located in network A and user B is located in network B. 
Ensure when user A subscribed to the User-to-User service 1 explicit request 
calls user B an User-to-user Indicator parameter is present set to 'Request 
service 1', 'not essential' or 'essential' in the encapsulated lAM of the initial 
INVTE request. 


Configuration 


User A is subscribed to the User-to-User service 1 explicit request 


SIP Parameter 


INVITE: 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

lAM 

User-to-user Indicator 

Request 

service 1 

not essential or essential 
User-to-user Information 

User Information 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE (lAM) ^ 
Apply post test routine 


Comments 


Check: Is an ISUP/BICC lAM encapsulated in the initial INVITE request? 
Check: Is a User-to-user Indicator parameter present in the encapsulated 

ISUP/BICC lAM? 
Check: Is the Request service 1 set to 'not essential' or 'essential'? 
Repeat this test in reverse direction. 
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Test case number 


SS uus 004 


Test case group 


SIP-SIP/SIP-I/UUS 


Reference 


7.1,6.5/[241 


SELECTION EXPRESSION 


([Network A] SE 1 7 AND SE 47) AND ([Network B] SE 1 7 AND SE 47) AND SE 
63 


Test purpose 


SIP-I support: Indicating of User-to-User service 1 explicit response in 180. 

BIGG/ISUP - SIP-I interworking applies in the originating and terminating network 
User A is located in network A and user B is located in network B. 
Ensure when user A subscribed to the User-to-User service 1 explicit request 
calls user B subscribed to User-to-User service 1 an User-to-user Indicator 
parameter is present set to 'Response', 'service 1 provided' in the encapsulated 
ACM of the 180 response. 


Configuration 


User A is subscribed to the User-to-User service 1 explicit request 


SIP Parameter 


INVITE: 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
lAM 

User-to-user Indicator 
Request 
service 1 
essential or not essential 

180 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
ACM 

User-to-user Indicator 
Response 
service 1 provided 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE (lAM) ^ 
^ 180 Ringing (ACM) 
Apply post test routine 


Comments 


Check: Is an ISUP/BICC lAM encapsulated in the initial INVITE request? 
Check: Is a User-to-user Information parameter present in the encapsulated 

ISUP/BICC lAM? 
Check: Is an ISUP/BICC ACM encapsulated in the 1 80 response? 
Check: Is an User-to-user Indicator parameter present set to 'Response', 

'service 1 provided' in the encapsulated ISUP/BICC ACM? 
Repeat this test in reverse direction. 
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Test case number 


SS uus 005 


Test case group 


SIP-SIP/SIP-I/UUS 


Reference 


7.1,6.5/[241 


SELECTION EXPRESSION 


([Network A] SE 1 7 AND SE 47) AND ([Network B] SE 1 7 AND SE 47) AND SE 
63 


Test purpose 


SIP-I support: Indicating of User-to-User service 1 not essential explicit 
rejected in 180. 

BIGG/ISUP - SIP-I interworking applies in the originating and terminating network 
User A is located in network A and user B is located in network B. 
Ensure when user A subscribed to the User-to-User service 1 explicit request 
calls user B not subscribed to User-to-User service 1 the call is rejected by the 
network an User-to-user Indicator parameter is present set to 'Response', 
'service 1 not provided' in the encapsulated ACM of the 180 response. 


Configuration 


User A is subscribed to the User-to-User service 1 explicit request 
User B is not subscribed to the User-to-User service 1 


SIP Parameter 


INVITE: 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
lAM 

User-to-user Indicator 
Request 
service 1 
not essential 

180 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
ACM 

User-to-user Indicator 
Response 
service 1 not provided 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE (lAM) ^ 
^ 180 Ringing (ACM) 
Apply post test routine 


Comments 


Check: Is an ISUP/BICC lAM encapsulated in the initial INVITE request? 
Check: Is a User-to-user Information parameter present in the encapsulated 

ISUP/BICC lAM? 
Check: Is an ISUP/BICC ACM encapsulated in the 1 80 response? 
Check: Is an User-to-user Indicator parameter present set to 'Response', 

'service 1 not provided' in the encapsulated ISUP/BICC ACM? 
Repeat this test in reverse direction. 
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Test case number 


SS uus 006 


Test case group 


SIP-SIP/SIP-I/UUS 


Reference 


6.11.2, 7.1/[24] 


SELECTION EXPRESSION 


([Network A] SE 1 7 AND SE 47) AND ([Network B] SE 1 7 AND SE 47) AND SE 
63 


Test purpose 


SIP-I support: Indicating of User-to-User service 1 essential explicit 
rejection. 

BICC/ISUP - SIP-I interworking applies in the originating and terminating network 
User A is located in network A and user B is located in network B. 
Ensure when user A subscribed to the User-to-User service 1 explicit request 
calls user B subscribed to User-to-User service 1 essential is rejected by the 
network or by the user. A 500 Server Internal Error is sent and an encapsulated 
ISUP/BICC REL is present, the Cause value is set to #29 or #69. 


Configuration 


User A is subscribed to the User-to-User service 1 explicit request 


SIP Parameter 


INVITE: 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
lAM 

User-to-user Indicator 
Request 
service 1 
essential 

500 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
REL 

Cause value 
#29 or #69 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE (lAM) ^ 
^ 500 Server Internal Error (REL) 

ACK ^ 
Apply post test routine 


Comments 


Check: Is an ISUP/BICC lAM encapsulated in the initial INVITE request? 
Check: Is a User-to-user Indicator parameter present in the encapsulated 

ISUP/BICC lAM set to 'Request', 'service 1', 'essential'? 
Check: Is an ISUP/BICC REL encapsulated in the 500 response? 
Check: Is the Cause value set to #29 or #69 in the encapsulated REL? 
Repeat this test in reverse direction. 
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Test case number 


SS uus 007 


Test case group 


SIP-SIP/SIP-I/UUS 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 63 


Test purpose 


SIP-I support: Indicating of User-to-User service 2 in initial INVITE request. 

BICC/ISUP - SIP-I interworking applies in the originating network User A is 
located in network A and user B is located in network B. 
Ensure when user A subscribed to the User-to-User service 2 calls user B an 
User-to-user Indicator parameter is present set to 'Request service 2', 'not 
essential' or 'essential' in the encapsulated lAM of the initial INVTE request. 


Configuration 


User A is subscribed to the User-to-User service 2 


SIP Parameter 


INVITE: 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
lAM 

User-to-user Indicator 
Request 
service 2 
not essential or 'essential' 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE (lAM) ^ 
Apply post test routine 


Comments 


Check: Is an ISUP/BICC lAM encapsulated in the initial INVITE request and 
the a User-to-user Indicator parameter is set to Is the Request 
service 2 'not essential' or 'essential'? 

Repeat this test in reverse direction. 
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Test case number 


SS uus 008 


Test case group 


SIP-SIP/SIP-I/UUS 


Reference 


5.4.3.2, 6.5, 7.1/[241 


SELECTION EXPRESSION 


([Network A] SE 1 7 AND SE 47) AND ([Network B] SE 1 7 AND SE 47) AND SE 
63 


Test purpose 


SIP-I support: Indicating of User-to-User service 2 in initial INVITE request 
successful. 

BIGC/ISUP - SIP-I interworking applies in the originating network User A is 
located in network A and user B is located in network B. 
Ensure when user A subscribed to the User-to-User service 2 calls user B an 
User-to-user Indicator parameter is present set to 'Request service 2', 'not 
essential' or 'essential' in the encapsulated lAM of the initial INVTE request. The 
User-to-User service is successful. 


Configuration 


User A is subscribed to the User-to-User service 2 
User B is subscribed to the User-to-User service 2 


SIP Parameter 


INVITE: 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
lAM 

User-to-user Indicator 
Request 
service 2 
not essential or 'essential' 

180 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
ACM 

User-to-user Indicator 
Response 
service 2 provided 

INFO 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
USR 

User-to-user Information 
User Information 

183 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
USR 

User-to-user Information 
User Information 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE (lAM) ^ 
^ 180 Ringing (ACM) 

INFO (USR) ^ 
^ 200 OK INFO 
^ 1 83 Session Progress (USR) 
Apply post test routine 


Comments 


Check: Is an ISUP/BICC lAM encapsulated in the initial INVITE request and 

the a User-to-user Indicator parameter is set to Is the Request 

service 2 'not essential' or 'essential'? 
Check: Is an ISUP/BICC ACM encapsulated in the 180 and the User-to-user 

Indicator parameter is set to 'Response', 'service 2 provided'? 
Check: Is an ISUP/BICC USR encapsulated in the INFO message sent from 

network A to network B containing an User-to-user Information 

parameter? 
Check: Is an ISUP/BICC USR encapsulated in the 183 response sent from 

network B to network A containing an User-to-user Information 

parameter? 
Repeat this test in reverse direction. 
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Test case number 


SS uus 009 


Test case group 


SIP-SIP/SIP-I/UUS 


Reference 


7.1,6.5/[241 


SELECTION EXPRESSION 


([Network A] SE 1 7 AND SE 47) AND ([Network B] SE 1 7 AND SE 47) AND SE 
63 


Test purpose 


SIP-I support: Indicating of User-to-User service 2 not essential rejected in 
180 response. 

BIGG/ISUP - SIP-I interworking applies in the originating and terminating network 
User A is located in network A and user B is located in network B. 
Ensure when user A subscribed to the User-to-User service 2 not essential calls 
user B not subscribed to User-to-User service 2 the call is rejected by the 
network an User-to-user Indicator parameter is present set to 'Response', 
'service 2 not provided' in the encapsulated ACM of the 180 response. 


Configuration 


User A is subscribed to the User-to-User service 2 
User B is not subscribed to the User-to-User service 2 


SIP Parameter 


INVITE: 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
lAM 

User-to-user Indicator 
Request 
service 2 
not essential 

180 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
ACM 

User-to-user Indicator 
Response 
service 2 not provided 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE (lAM) ^ 
^ 180 Ringing (ACM) 
Apply post test routine 


Comments 


Check: Is an ISUP/BICC lAM encapsulated in the initial INVITE request? 
Check: Is a User-to-user Information parameter present in the encapsulated 

ISUP/BICC lAM set to 'Request', 'service 2' 'not essential'? 
Check: Is an ISUP/BICC ACM encapsulated in the 1 80 response? 
Check: Is an User-to-user Indicator parameter present set to 'Response', 

'service 2 not provided' in the encapsulated ISUP/BICC ACM? 
Repeat this test in reverse direction. 
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Test case number 


SS uus 010 


Test case group 


SIP-SIP/SIP-I/UUS 


Reference 


6.11.2, 7.1/[24] 


SELECTION EXPRESSION 


([Network A] SE 1 7 AND SE 47) AND ([Network B] SE 1 7 AND SE 47) AND SE 
63 


Test purpose 


SIP-I support: Indicating of User-to-User service 2 essential rejection. 

BICC/ISUP - SIP-I interworking applies in the originating and terminating network 
User A is located in network A and user B is located in network B. 
Ensure when user A subscribed to the User-to-User service 2 essential calls 
user B not subscribed to User-to-User service 2 the call is rejected by the 
network. A 500 Server Internal Error is sent and an encapsulated ISUP/BICC 
REL is present, the Cause value is set to #29 or #69. 


Configuration 


User A is subscribed to the User-to-User service 2 


SIP Parameter 


INVITE: 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
lAM 

User-to-user Indicator 
Request 
service 2 
essential 

500 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
REL 

Cause value 
#29 or #69 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE (lAM) ^ 
^ 500 Server Internal Error (REL) 

ACK ^ 
Apply post test routine 


Comments 


Check: Is an ISUP/BICC lAM encapsulated in the initial INVITE request? 
Check: Is a User-to-user Indicator parameter present in the encapsulated 

ISUP/BICC lAM set to 'Request', 'service 1', 'essential'? 
Check: Is an ISUP/BICC REL encapsulated in the 500 response? 
Check: Is the Cause value set to #29 or #69 in the encapsulated REL? 
Repeat this test in reverse direction. 
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Test case number 


SS uus 011 


Test case group 


SIP-SIP/SIP-I/UUS 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 63 


Test purpose 


SIP-I support: Indicating of User-to-User service 3 in initial INVITE request. 

BICC/ISUP - SIP-I interworking applies in the originating network User A is 
located in network A and user B is located in network B. 
Ensure when user A subscribed to the User-to-User service 3 calls user B an 
User-to-user Indicator parameter is present set to 'Request service 3', 'not 
essential' or 'essential' in the encapsulated lAM of the initial INVTE request. 


Configuration 


User A is subscribed to the User-to-User service 3 


SIP Parameter 


INVITE: 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
lAM 

User-to-user Indicator 
Request 
service 3 
not essential or 'essential' 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE (lAM) ^ 
Apply post test routine 


Comments 


Check: Is an ISUP/BICC lAM encapsulated in the initial INVITE request and 
the a User-to-user Indicator parameter is set to Is the Request 
service 3 'not essential' or 'essential'? 

Repeat this test in reverse direction. 
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Test case number 


SS uus 012 


Test case group 


SIP-SIP/SIP-I/UUS 


Reference 


5.4.3.2, 6.5, 7.1/[241 


SELECTION EXPRESSION 


([Network A] SE 1 7 AND SE 47) AND ([Network B] SE 1 7 AND SE 47) AND SE 
63 


Test purpose 


SIP-I support: Indicating of User-to-User service 3 in initial INVITE request 
successful. 

BICC/ISUP - SIP-I interworking applies in the originating network User A is 
located in network A and user B is located in network B. 
Ensure when user A subscribed to the User-to-User service 3 calls user B an 
User-to-user Indicator parameter is present set to 'Request service 3', 'not 
essential' or 'essential' in the encapsulated lAM of the initial INVTE request. The 
User-to-User service is successful. 


Configuration 


User A is subscribed to the User-to-User service 3 
User B is subscribed to the User-to-User service 3 


SIP Parameter 


INVITE: 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
lAM 

User-to-user Indicator 
Request 
service 3 
not essential or 'essential' 

200 OK 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
ANM 

User-to-user Indicator 
Response 
service 3 provided 

INFO 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
USR 

User-to-user Information 
User Information 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE (lAM) ^ 
^ 180 Ringing (ACM) 
^ 200 OK INVITE (ANM) 

ACK ^ 
INFO (USR) ^ 
^ 200 OK INFO 
^ INFO (USR) 

200 OK INFO ^ 
Apply post test routine 


Comments 


Check: Is an ISUP/BICC lAM encapsulated in the initial INVITE request and 
the 

a User-to-user Indicator parameter is set to Is the Request service 3 

'not essential' or 'essential'? 
Check: Is an ISUP/BICC ANM encapsulated in the 200 OK INVITE and the 

User-to-user Indicator parameter is set to 'Response', 'service 3 

provided'? 
Check: Is an ISUP/BICC USR encapsulated in the INFO message sent from 

network A to network B containing an User-to-user Information 

parameter? 
Check: Is an ISUP/BICC USR encapsulated in the INFO message sent from 

network B to network A containing an User-to-user Information 

parameter? 
Repeat this test in reverse direction. 
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Test case number 


SS uus 013 


Test case group 


SIP-SIP/SIP-I/UUS 


Reference 


7.1,6.5/[241 


SELECTION EXPRESSION 


([Network A] SE 1 7 AND SE 47) AND ([Network B] SE 1 7 AND SE 47) AND SE 
63 


Test purpose 


SIP-I support: Indicating of User-to-User service 3 not essential rejected in 
200 OK response. 

BIGG/ISUP - SIP-I interworking applies in the originating and terminating network 
User A is located in network A and user B is located in network B. 
Ensure when user A subscribed to the User-to-User service 3 not essential calls 
user B not subscribed to User-to-User service 3 the call is rejected by the 
network an User-to-user Indicator parameter is present set to 'Response', 
'service 3 not provided' in the encapsulated ANM of the 200 OK final response. 


Configuration 


User A is subscribed to the User-to-User service 3 
User B is not subscribed to the User-to-User service 3 


SIP Parameter 


INVITE: 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
lAM 

User-to-user Indicator 
Request 
service 3 
not essential 

200 OK 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
ANM 

User-to-user Indicator 
Response 
service 3 not provided 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE (lAM) ^ 
^ 180 Ringing (ACM) 
^ 200 OK INVITE (ANM) 

ACK ^ 
Apply post test routine 


Comments 


Check: Is an ISUP/BICC lAM encapsulated in the initial INVITE request? 
Check: Is a User-to-user Information parameter present in the encapsulated 

ISUP/BICC lAM set to 'Request', 'service 3' 'not essential'? 
Check: Is an ISUP/BICC ANM encapsulated in the 200 OK response? 
Check: Is an User-to-user Indicator parameter present set to 'Response', 

'service 3 not provided' in the encapsulated ISUP/BICC ANM? 
Repeat this test in reverse direction. 
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Test case number 


SS uus 014 


Test case group 


SIP-SIP/SIP-I/UUS 


Reference 


6.11.2, 7.1/[24] 


SELECTION EXPRESSION 


([Network A] SE 1 7 AND SE 47) AND ([Network B] SE 1 7 AND SE 47) AND SE 
63 


Test purpose 


SIP-I support: Indicating of User-to-User service 3 essential rejection. 

BICC/ISUP - SIP-I interworking applies in the originating and terminating network 
User A is located in network A and user B is located in network B. 
Ensure when user A subscribed to the User-to-User service 3 essential calls 
user B not subscribed to User-to-User service 3 the call is rejected by the 
network. A 500 Server Internal Error is sent and an encapsulated ISUP/BICC 
REL is present, the Cause value is set to #29 or #69. 


Configuration 


User A is subscribed to the User-to-User service 3 


SIP Parameter 


INVITE: 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
lAM 

User-to-user Indicator 
Request 
service 3 
essential 

500 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
REL 

Cause value 
#29 or #69 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE (lAM) ^ 
^ 500 Server Internal Error (REL) 

ACK ^ 
Apply post test routine 


Comments 


Check: Is an ISUP/BICC lAM encapsulated in the initial INVITE request? 
Check: Is a User-to-user Indicator parameter present in the encapsulated 

ISUP/BICC lAM set to 'Request', 'service 1', 'essential'? 
Check: Is an ISUP/BICC REL encapsulated in the 500 response? 
Check: Is the Cause value set to #29 or #69 in the encapsulated REL? 
Repeat this test in reverse direction. 
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Test case number 


SS uus 015 


Test case group 


SIP-SIP/SIP-I/UUS 


Reference 


5.4.3.2, 6.5, 7.1/f24l 


SELECTION EXPRESSION 


([Network A] SE 1 7 AND SE 47) AND ([Network B] SE 1 7 AND SE 47) AND SE 
63 


Test purpose 


SIP-I support: Indicating of User-to-User service 3 during a session is 
established successful. 

BICC/ISUP - SIP-I interworking applies in the originating network User A is 
located in network A and user B is located in network B. 
Ensure when user A subscribed to the User-to-User service 3 user A is able to 
request the User-to-User service 3 while the session is established. The User-to- 
User service is successful. 


Configuration 


User A is subscribed to the User-to-User service 3 
User B is subscribed to the User-to-User service 3 


SIP Parameter 


INFO: 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
FAR 

Facility indicator 

user-to-user service 
User-to-user Indicator 
Request 
service 3 
not essential 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
FAA 

Facility indicator 

user-to-user service 
User-to-user Indicator 
Response 
service 3 provided 

INFO 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
USR 

User-to-user Information 
User Information 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

A session is already established 

INFO (FAR) ^ 
^ 200 OK INFO 
^ INFO (FAA) 

200 OK INFO ^ 

INFO (USR) ^ 
^ 200 OK INFO 
^ INFO (USR) 

200 OK INFO ^ 
Apply post test routine 
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Comments 


A session is already established 

Check: Is an ISUP/BICC FAR encapsulated in the INFO request sent from 

Network A to Network B and the a User-to-user Indicator parameter is 

set to Is the Request service 3 'not essential'? 
Check: Is an ISUP/BICC FAA encapsulated in the INFO request sent from 

Network B to Network A and the User-to-user Indicator parameter is 

set to 'Response', 'service 3 provided'? 
Check: Is an ISUP/BICC USR encapsulated in the INFO message sent from 

network A to network B containing an User-to-user Information 

parameter? 
Check: Is an ISUP/BICC USR encapsulated in the INFO message sent from 

network B to network A containing an User-to-user Information 

parameter? 
Repeat this test in reverse direction. 



Test case number 


SS uus 016 


Test case group 


SIP-SIP/SIP-I/UUS 


Reference 


5.4.3.2, 6.5, 7.1/[24] 


SELECTION EXPRESSION 


([Network A] SE 17 AND SE 47) AND ([Network B] SE 17 AND SE 47) AND SE 
63 


Test purpose 


SIP-I support: Indicating of User-to-User service 3 during a session is 
established unsuccessful. 

BICC/ISUP - SIP-I interworking applies in the originating network User A is 
located in network A and user B is located in network B. 
Ensure when user A subscribed to the User-to-User service 3 user A is able to 
request the User-to-User service 3 while the session is established. The service 
request is rejected by Network B. 


Configuration 


User A is subscribed to the User-to-User service 3 
User B is not subscribed to the User-to-User service 3 


SIP Parameter 


INFO: 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
FAR 

Facility indicator 

user-to-user service 
User-to-user Indicator 
Request 
service 3 
not essential 

INFO: 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
FRJ 

Facility indicator 

user-to-user service 
User-to-user Indicator 
Response 
service 3 not provided 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

A session is already established 

INFO (FAR) ^ 
^ 200 OK INFO 
^ INFO (FRJ) 

200 OK INFO ^ 
Apply post test routine 


Comments 


A session is already established 

Check: Is an ISUP/BICC FAR encapsulated in the INFO request sent from 

Network A to Network B and the a User-to-user Indicator parameter is 

set to Is the Request service 3 'not essential'? 
Check: Is an ISUP/BICC FAA encapsulated in the INFO request sent from 

Network B to Network A and the User-to-user Indicator parameter is 

set to 'Response', 'service 3 not provided'? 
Repeat this test in reverse direction. 
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7.1.6.2 



Subaddressing (SUB) 



Test case number 


SS sub 001 


Test case group 


SIP-SIP/SIP-I/SUB 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 62 


Test purpose 


SIP-I support: Calling party subaddress can be correctly transferred in the 
Access Transport parameters. 

BICC/ISUP - SIP-I interworking applies in the originating network User A is 
located in network A and user B is located in network B. Ensure that an 
ISUP/BICC ATP parameter present in the encapsulated lAM of the INVITE 
request and contains a Calling party subaddress. 


Configuration 


User A is subscribed to the SUB supplementary service 


SIP Parameter 


INVITE 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

lAM 

Access transport 

Calling party subaddress 
-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(IAM) ^ 


Comments 


Establish a call from User A subscribed to the SUB supplementary service to 
user B 

Check: Is an ISUP/BICC lAM present in the initial INVITE request? 
Check: Is an ISUP/BICC ATP parameter present in the encapsulated lAM 

containing a Calling party subaddress? 
Repeat this test in reverse direction. 



Test case number 


SS sub 002 


Test case group 


SIP-SIP/SIP-I/SUB 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 62 


Test purpose 


SIP-I support. Called party subaddress can be correctly transferred in the 
Access Transport parameters. 

BICC/ISUP - SIP-I interworking applies in the originating network User A is 
located in network A and user B is located in network B. Ensure that an 
ISUP/BICC ATP parameter present in the encapsulated lAM of the INVITE 
request and contains a Called party subaddress. 


Configuration 


User A is subscribed to the SUB supplementary service 


SIP Parameter 


INVITE 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 

Content-Disposition: signal;handling=required 

JAM 

Access transport 

Called party subaddress 
-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(IAM) ^ 
Apply post test routine 


Comments 


Check: Is the BICC/ISUP ANM encapsulated in the 200 OK INVITE final 

response? 
Check: Is an ISUP/BICC ATP parameter present in the encapsulated ANM 

containing a Called party subaddress? 
Repeat this test in reverse direction. 
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Test case number 


SS sub 003 


Test case group 


SIP-SIP/SIP-I/SUB 


Reference 


6.7/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 62 


Test purpose 


SIP-I support. Connected party subaddress can be correctly transferred in 
the Access Transport parameters. 

BICC/ISUP - SIP-I interworking applies in the terminating network User A is 
located in network A and user B is located in network B. Ensure that an 
ISUP/BICC ATP parameter present in the encapsulated ANM of the 200 OK 
INVITE final response and a Connected party subaddress is contained. 


Configuration 


User B is subscribed to the SUB supplementary service 


SIP Parameter 


200 OK INVITE 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

ANM 

Access transport 

Connected party subaddress 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(IAM) ^ 
^ 180Ringing(ACM) 
^ 200 OK INVITE(ANM) 

ACK ^ 
Apply post test routine 


Comments 


Check: Is the BICC/ISUP ANM encapsulated in the 200 OK INVITE final 

response? 
Check: Is an ISUP/BICC ATP parameter present in the encapsulated ANM 

containing a Called party subaddress? 
Repeat this test in reverse direction. 
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7.1.6.3 



Ternninal Portability (TP) 



Test case number 


SS tp 001 


Test case group 


SIP-SIP/SIP-I/TP 


Reference 


5.4.3.2/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 64 


Test purpose 


SIP-I support. SUS and RES messages transferred in an INFO request. 

BICC/ISUP - SIP-I interworking applies in the originating network User A is 
located in network A and user B is located in network B. A session is already 
established. Ensure that an INFO request is sent from Network A to Network B 
and an ISUP SUS message is encapsulated containing a Suspend/resume 
indicator set to ISDN subscriber initiated. Ensure that an INFO request is sent 
from Network A to Network B and an ISUP RES message is encapsulated 
containing a Suspend/resume indicator set to ISDN subscriber initiated. 


Configuration 


User A is subscribed to the Terminal Portability supplementary service 


SIP Parameter 


INFO 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
SUS 

Suspend/resume indicator 
ISDN subscriber initiated 

INFO 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
RES 

Suspend/resume indicator 
ISDN subscriber initiated 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

A confirmed session already exists 

INFO(SUS) ^ 
^ 200 OK INFO 

INFO(RES) ^ 
^ 200 OK INFO 

Apply post test routine 


Comments 


A session is already established 

Check: Is an ISUP SUS message encapsulated in the INFO request and the 

Suspend/resume indicator set to 'ISDN subscriber initiated'? 
Check: Is an ISUP RES message encapsulated in the INFO request and the 

Suspend/resume indicator set to 'ISDN subscriber initiated'? 
Repeat this test in reverse direction. 
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Test case number 


SS tp 002 


Test case group 


SIP-SIP/SIP-I/TP 


Reference 


5.4.3.2, 6.11.2, 6.11. 2/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 64 


Test purpose 


SIP-I support. SUS message transferred in an INFO request call released. 

BIGG/ISUP - SIP-I interworking applies in the originating network User A is 
located in network A and user B is located in network B. A session is already 
established. Ensure that an INFO request is sent from Network A to Network B 
and an ISUP SUS message is encapsulated containing a Suspend/resume 
indicator set to ISDN subscriber initiated. Ensure that an BYE request is sent 
from Network A to Network B and an ISUP REL message is encapsulated 
containing a Cause value set to #102. 


Configuration 


User A is subscribed to the Terminal Portability supplementary service 


SIP Parameter 


INFO 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
SUS 

Suspend/resume indicator 
ISDN subscriber initiated 

BYE 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
REL 

Location 

public network serving remote user 
Cause value 
102 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

A confirmed session already exists 

INFO(SUS) ^ 
^ 200 OK INFO 

BYE(REL) ^ 
^ 200 OK BYE 


Comments 


A session is already established 

Check: Is an ISUP SUS message encapsulated in the INFO request and the 

Suspend/resume indicator set to ISDN 'subscriber initiated'? 
Check: Is an ISUP REL message encapsulated in the BYE request and the 

Cause value set to #102? 
Repeat this test in reverse direction. 
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7.2 



Number Portability 



Test case number 


SS NP 001 


Test case group 


SIP-SIP/NubP 


Reference 


5.3, 5.4/f21 


SELECTION EXPRESSION 


[Network A] SE 13 


Test purpose 


Request line in the INVITE contains the number portability indication. 

User A attempts to call user B ported to network B. Ensure that the userinfo in 
the INVITE contains a destination number in the global number format, an 'rn' 
parameter containing the Number Portability Routing Number in a global number 
format with hex digits and optional the 'npdi' parameter. 


Configuration 




SIP Parameter 


INVITE: Request line 

sip: + <CC> <NDC> <SN>[;npdi][; rn=(Number portability routing number)] 
@<hostname>;user = phone SIP/2.0 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
Apply post test routine 


Comments 


Check: Is the URI in the userinfo of the Request line in a global number 

format? 
Check: Is the URI rn parameter containing the Number Portability Routing 

Number in a global number format? 
Check: Is optional the URI parameter 'npdi' present? 
Check: Is the user parameter set to 'phone'? 
Repeat this test in reverse direction. 



Test case number 


SS NP 002 


Test case group 


SIP-SIP/NubP 


Reference 


5.3, 5.4/f21 


SELECTION EXPRESSION 


NOT[NetworkA]SE13 


Test purpose 


Request line in the INVITE without npdi parameter. 

The Network A does not have a Number Portability database. User A attempts to 
call user B ported to network B. Ensure that the userinfo in the INVITE contains 
a destination number in a global number format and a npdi URI parameter is not 
present. 


Configuration 




SIP Parameter 


INVITE: Request line 

sip: + <CC> <NDC> <SN>@<hostname>;user = phone SIP/2.0 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
Apply post test routine 


Comments 


Check: Is the URI in the userinfo of the Request line in a global number format 

without npdi parameter and number portability routing number? 
Check: Is the user parameter set to 'phone'? 
Repeat this test in reverse direction. 
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7.3 Accounting 



Test case number 


SS ace 001 


Test case group 


SIP-SIP/ACCOUNTING 


Reference 




SELECTION EXPRESSION 




Test purpose 


Comparison of Charging Data Records > 1 s. 

Accounting of a confirmed session with a duration > 1 s. Verify the duration of 
the active session stored in the CDR of both networks compared with the 
duration in the monitored message flow at the Interconnection Interface. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 180 Ringing 
^ 200 OK INVITE 

ACK ^ 
Communication 

BYE ^ 
^ 200 OK BYE 


Comments 


1 . Setup a call from network A to network B. 

2. Verify is the session confirmed. 

3. Terminate the session after 5 s. 

4. Determine the duration of the session from the trace of the call monitor. 

5. Compare the following information elements indicated in the CDR's of both 
networks: 

• calling party number 

• called party number 

• timestamp 

• callduration 

• callsetuptime (optional) 

6. Check the duration indicated in the CDR against the duration in the call 
trace. 

7. Repeat this test in reverse direction. 
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Test case number 


SS ace 002 


Test case group 


SIP-SIP/AGGOUNTING 


Reference 




SELECTION EXPRESSION 




Test purpose 


Comparison of Charging Data Records < 1 s 

Accounting of a confirmed session with a duration of < 1 min. Verify the duration 
of the active session stored in the GDR of both networks compared with the 
duration in the monitored message flow at the Interconnection Interface. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 180 Ringing 
^ 200 OK INVITE 

ACK ^ 
Communication 

BYE ^ 
^ 200 OK BYE 


Comments 


1 . Setup a call from network A to network B. 

2. Verify is the session confirmed. 

3. Terminate the session after 5 s. 

4. Determine the duration of the session from the trace of the call monitor. 

5. Compare the following information elements indicated in the GDR's of both 
networks: 

• calling party number 

• called party number 

• timestamp 

• callduration 

• callsetuptime (optional) 

6. Check the duration indicated in the CDR against the duration in the call 
trace. 

7. Repeat this test in reverse direction. 
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Test case number 


SS ace 003 


Test case group 


SIP-SIP/AGGOUNTING 


Reference 




SELECTION EXPRESSION 




Test purpose 


Comparison of Charging Data Records > 15 min. 

Accounting of a confirmed session with a duration of > 15 min. Verify the 
duration of the active session stored in the GDR of both networks compared with 
the duration in the monitored message flow at the Interconnection Interface. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 180 Ringing 
^ 200 OK INVITE 

ACK ^ 
Communication 

BYE ^ 
^ 200 OK BYE 


Comments 


1 . Setup a call from network A to network B. 

2. Verify is the session confirmed. 

3. Terminate the session after 1 5 min. 

4. Determine the duration of the session from the trace of the call monitor. 

5. Compare the following information elements indicated in the GDR's of both 
networks: 

• calling party number 

• called party number 

• timestamp 

• callduration 

• callsetuptime (optional) 

6. Check the duration indicated in the CDR against the duration in the call 
trace. 

7. Repeat this test in reverse direction. 
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Test case number 


SS ace 004 


Test case group 


SIP-SIP/AGGOUNTING 


Reference 




SELECTION EXPRESSION 




Test purpose 


Comparison of Charging Data Records 25 min. 

Accounting of a confirmed session with a duration of 25 min. Verify the duration 
of the active session stored in the GDR of both networks compared with the 
duration in the monitored message flow at the Interconnection Interface. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 180 Ringing 
^ 200 OK INVITE 

ACK ^ 
Communication 

BYE ^ 
^ 200 OK BYE 


Comments 


1 . Setup a call from network A to network B. 

2. Verify is the session confirmed. 

3. Terminate the session after 25 min. 

4. Determine the duration of the session from the trace of the call monitor. 

5. Compare the following information elements indicated in the GDR's of both 
networks: 

• calling party number 

• called party number 

• timestamp 

• callduration 

• callsetuptime (optional) 

6. Check the duration indicated in the CDR against the duration in the call 
trace. 

7. Repeat this test in reverse direction. 
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Test case number 


SS ace 005 


Test case group 


SIP-SIP/AGGOUNTING 


Reference 




SELECTION EXPRESSION 




Test purpose 


Comparison of Charging Data Records more than 30 min. 

Accounting of a confirmed session with a duration of > 30 min. Verify the 
duration of the active session stored in the GDR of both networks compared with 
the duration in the monitored message flow at the Interconnection Interface. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 180 Ringing 
^ 200 OK INVITE 

ACK ^ 
Communication 

BYE ^ 
^ 200 OK BYE 


Comments 


1 . Setup a call from network A to network B. 

2. Verify is the session confirmed. 

3. Terminate the session after 35 min. 

4. Determine the duration of the session from the trace of the call monitor. 

5. Compare the following information elements indicated in the GDR's of both 
networks: 

• calling party number 

• called party number 

• timestamp 

• callduration 

• callsetuptime (optional) 

6. Check the duration indicated in the CDR against the duration in the call 
trace. 

7. Repeat this test in reverse direction. 
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Test case number 


SS ace 006 


Test case group 


SIP-SIP/AGGOUNTING 


Reference 




SELECTION EXPRESSION 




Test purpose 


Comparison of Charging Data Records more than 60 min. 

Accounting of a confirmed session with a duration between 60 min and 120 min. 
Verify the duration of the active session stored in the GDR of both networks 
compared with the duration in the monitored message flow at the Interconnection 
Interface. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
4- 180 Ringing 
^ 200 OK INVITE 

ACK ^ 
Communication 

BYE ^ 
^ 200 OK BYE 


Comments 


1 . Setup a call from network A to network B. 

2. Verify is the session confirmed. 

3. Terminate the session at the earliest 61 min and at the latest 1 1 9 min. 

4. Determine the duration of the session from the trace of the call monitor. 

5. Compare the following information elements indicated in the GDR's of both 
networks: 

• calling party number 

• called party number 

• timestamp 

• callduration 

• callsetuptime (optional) 

6. Check the duration indicated in the CDR against the duration in the call 
trace. 

7. Repeat this test in reverse direction. 
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Test case number 


SS ace 007 


Test case group 


SIP-SIP/AGGOUNTING 


Reference 




SELECTION EXPRESSION 




Test purpose 


Comparison of Charging Data Records more than 24 hours. 

Accounting of a confirmed session with duration > 24 h with change of date. 
Verify the duration of the active session stored in the GDR of both networks 
compared with the duration in the monitored message flow at the Interconnection 
Interface. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
4- 180 Ringing 
^ 200 OK INVITE 

ACK ^ 
Communication 

BYE ^ 
^ 200 OK BYE 


Comments 


1 . Setup a call from network A to network B. 

2. Verify is the session confirmed. 

3. Terminate the session after 24 hours. 

4. Determine the duration of the session from the trace of the call monitor. 

5. Compare the following information elements indicated in the GDR's of both 
networks: 

• calling party number 

• called party number 

• timestamp 

• callduration 

• callsetuptime (optional) 

6. Check the duration indicated in the CDR against the duration in the call 
trace. 

7. Repeat this test in reverse direction. 
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Test case number 


SS ace 008 


Test case group 


SIP-SIP/AGGOUNTING 


Reference 




SELECTION EXPRESSION 




Test purpose 


Comparison of Charging Data Records less than 1 s. 

Accounting of a confirmed session with duration <1 s. Verify the duration of the 
active session stored in the GDR of both networks compared with the duration in 
the monitored message flow at the Interconnection Interface. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
^ 180 Ringing 
^ 200 OK INVITE 

ACK ^ 
Communication 

BYE ^ 
^ 200 OK BYE 


Comments 


1 . Setup a call from network A to network B. 

2. Verify is the session confirmed. 

3. Terminate the session after 0,9 s. 

4. Determine the duration of the session from the trace of the call monitor. 

5. Compare the following information elements indicated in the GDR's of both 
networks: 

• calling party number 

• called party number 

• timestamp 

• callduration 

• callsetuptime (optional) 

6. Check the duration indicated in the CDR against the duration in the call 
trace. 

7. Repeat this test in reverse direction. 
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Test case number 


SS ace 009 


Test case group 


SIP-SIP/ACCOUNTING 


Reference 




SELECTION EXPRESSION 




Test purpose 


Comparison of Charging Data Records session not confirmed. 

Accounting of an unsuccessful session in the early dialogue. Verify the duration 
of the call attempt stored in the CDR of both networks compared with the 
duration in the monitored message flow at the Interconnection Interface if 
applicable. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
4- 180 Ringing 

BYE/CANCEL ^ 
^ 200 OK BYE/CANCEL 
4- 487 Request Terminated 

ACK ^ 


Comments 


1 . Setup a call from network A to network B. 

2. Verify is an early dialogue established. 

3. Terminate the early dialogue after 20 s. 

4. Determine the duration of the session from the trace of the call monitor. 

5. Compare the following information elements indicated in the GDR's of both 
networks: 

• calling party number 

• called party number 

• timestamp 

• callduration 

• callsetuptime (optional) 

6. Check the duration indicated in the CDR against the duration in the call 
trace. 

7. Repeat this test in reverse direction. 



ETSI 



241 



ETSI TS 101 585 VI .1.2 (2012-09) 



7.4 



Carrier Selection 



Test case number 


SS csel 001 


Test case group 


SIP-SIP/CS 


Reference 


5.7.1.10/f2] 


SELECTION EXPRESSION 


[Network A] SE14 AND [Network B] SE15 


Test purpose 


User selects an operator 'call-by-call'. 

User A and user B are located in network A. Ensure that user A is able to call 
user B and user A is able to select network B as a selected carrier 'call-by-call'. 


Configuration 


User in network A is not presubscribed 


SIP Parameter 


INVITE: Request line 

sip: + <CC> <NDC> <SN>[;cic=(carrier ID)]@<hostname> user=phone SIP/2.0 

INVITE: Request line 

sip: + <CC> <NDC> <SN>;npdi 

[;rn=<Number portability routing number>]@<hostname>; 
user=phone SIP/2.0 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 1 ^ 
^ INVITE 2 

Apply post test routine 


Comments 


Check: Is the 'cic' tel uri parameter present in the Request URI in the INVITE 

sent from network A to network B identifying the selected carrier? 
Check: Is the 'npdi' parameter present in the Request URI of the INVITE 

request sent from network B to network A? 
Check: Is optional the 'rn' parameter present in the Request URI of the INVITE 

request sent from network B to network A? 
NOTE 1 : The 'cic' parameter may be absent according national regulations or 

national agreements. 
NOTE 2: It is possible that further informations are available in the Request line 

regarding the end user charging in case of Carrier selection. 
Repeat this test in reverse direction. 
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Test case number 


SS csel 002 


Test case group 


SIP-SIP/CS 


Reference 


5.7.1.10/[2] 


SELECTION EXPRESSION 


[Network A] SE14 AND [Network B] SE15 


Test purpose 


User is presubscribed to operator B. 

User A and user B are located in network A. Ensure that user A is able to call 
user B and user A is preselected to network B as a selected carrier. 


Configuration 


User in network A is presubscribed to network B 


SIP Parameter 


INVITE: Request line 

sip: + <CC> <NDC> <SN>[;cic=(carrier ID)]@<hostname> user=phone SIP/2.0 

INVITE: Request line 

sip: + <CC> <NDC> <SN>;npdi 

[;rn=<Number portability routing number>]@<hostname>; 
user=phone SIP/2.0 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 1 ^ 
^ INVITE 2 

Apply post test routine 


Comments 


Check: Is the 'cic' tel uri parameter present in the Request URI in the INVITE 

sent from network A to network B identifying the selected carrier? 
Check: Is the 'npdi' parameter present in the Request URI of the INVITE 

request sent from network B to network A? 
Check: Is optional the 'rn' parameter present in the Request URI of the INVITE 

request sent from network B to network A? 
NOTE 1 : The 'cic' parameter may be absent according national regulations or 

national agreements. 
NOTE 2: It is possible that further informations are available in the Request line 

regarding the end user charging in case of Carrier selection. 
Repeat this test in reverse direction. 



ETSI 



243 



ETSI TS 101 585 VI .1.2 (2012-09) 



Test case number 


SS csel 003 


Test case group 


SIP-SIP/CS 


Reference 


5.7.1.10/[2] 


SELECTION EXPRESSION 


[Network A] SE14 AND [Network B] SE15 


Test purpose 


User is presubscribed to an operator unequal to B, and overrides the 
preselection with call-by-call via operator B. 

User A and user B are located in network A. User A is preselected to a network 
unequal to network B. Ensure that user A is able to call user B and user A is able 
to select network B as a selected carrier 'call-by-call'. The preselected carrier is 
ignored. 


Configuration 


User in network A is presubscribed to network B 


SIP Parameter 


INVITE: Request line 

sip: + <CC> <NDC> <SN>[;cic=(carrier ID)]@<hostname> user=phone SIP/2.0 

INVITE: Request line 

sip: + <CC> <NDC> <SN>;npdi 

[;rn=<Number portability routing number>]@<hostname>; 
user=phone SIP/2.0 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 1 ^ 
^ INVITE 2 

Apply post test routine 


Comments 


Check: Is the 'cic' tel uri parameter present in the Request URI in the INVITE 

sent from network A to network B identifying the selected carrier? 
Check: Is the 'npdi' parameter present in the Request URI of the INVITE 

request sent from network B to network A? 
Check: Is optional the Yn' parameter present in the Request URI of the INVITE 

request sent from network B to network A? 
NOTE 1 : The 'cic' parameter may be absent according national regulations or 

national agreements. 
NOTE 2: It is possible that further informations are available in the Request line 

regarding the end user charging in case of Carrier selection. 
Repeat this test in reverse direction. 
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Test case number 


SS csel 004 


Test case group 


SIP-SIP/CS 


Reference 


5.7.1.10/[2] 


SELECTION EXPRESSION 


[Network A] SE14 AND [Network B] SE15 


Test purpose 


User is presubscribed to an operator not operator B, and overrides the 
preselection with call-by-call via operator B. 

User A and user B are located in network A. User A is preselected to a network 
unequal to network B. Ensure that user A is able to call user B and user A is able 
to select network B as a selected carrier 'call-by-call'. The preselected carrier is 
ignored. 


Configuration 


User in network A is presubscribed not to network B 


SIP Parameter 


INVITE: Request line 

sip: + <CC> <NDC> <SN>[;cic=(carrier ID)]@<hostname> user=phone SIP/2.0 

INVITE: Request line 

sip: + <CC> <NDC> <SN>;npdi 

[;rn=<Number portability routing number>]@<hostname>; 
user=phone SIP/2.0 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 1 ^ 
^ INVITE 2 

Apply post test routine 


Comments 


Check: Is the 'cic' tel uri parameter present in the Request URI in the INVITE 

sent from network A to network B identifying the selected carrier? 
Check: Is the 'npdi' parameter present in the Request URI of the INVITE 

request sent from network B to network A? 
Check: Is optional the Yn' parameter present in the Request URI of the INVITE 

request sent from network B to network A? 
NOTE 1 : The 'cic' parameter may be absent according national regulations or 

national agreements. 
NOTE 2: It is possible that further informations are available in the Request line 

regarding the end user charging in case of Carrier selection. 
Repeat this test in reverse direction. 
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Test case number 


SS csel 005 


Test case group 


SIP-SIP/CS 


Reference 




SELECTION EXPRESSION 


[Network A] SE14 AND [Network B] SE15 AND [Network A] SE34 


Test purpose 


User is preselected to operator B. Transit of CUG information -OA. 

An originating user in a CUG Outgoing Access not allowed preselected to 
Network B and calls to a user in the same CUG. The session establishment is 
successful. 


Configuration 


User in network A is presubscribed to network B 
Users in network A are in the same CUG 


SIP Parameter 


INVITE: Request line 

sip: + <CC> <NDC> <SN>@tariff.<hostname> 
user=phone SIP/2.0 

Content-Type: application/vnd.etsi.cug+xml 
Content-Disposition: ....;handling= required 

<...:cug> 

<..: cugCommunicationlndicator>11 </...: cugCommunicationlndicator> 
<...:cug> 

INVITE: Request line 

sip: + <CC> <NDC> <SN@<hostname>;user=phone SIP/2.0 

Content-Type: application/vnd.etsi.cug+xml 
Content-Disposition: ....;handling= required 

<...:cug> 

<..: cugCommunicationlndicator>11 </...: cugCommunicationlndicator> 
<...:cug> 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 1 ^ 
^ INVITE 2 

Apply post test routine 


Comments 


Check: Is the sub domain pattern 'tariff present at the beginning of the 

hostportion only of the initial INVITE sent from network A to 

network B? 
Check: Is the 'npdi' parameter present in the userinfo of the INVITE request 

sent from network B to network A? 
Check: Is optional the 'rn' parameter present in the userinfo of the INVITE 

request sent from network B to network A? 
Check: Contains the XML body in the INVITE a 'cugCommunicationlndicator' 

element set to '11 ' as a 'cug' child element? 
Check: Is the session setup not rejected? 
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7.5 Emergency call 



Test case number 


SS ecall 001 


Test case group 


SIP-SIP/EmC 


Reference 


5.2.10, 5.7.1. 14/[21 


SELECTION EXPRESSION 




Test purpose 


Request line in the INVITE. 

User A attempts to call a PSAP located in network B. Ensure that the Request 
line in the INVITE contains the emergency number and a 'rn' parameter 
containing the PSAP routing number. In addition a location information may be 
present: 

• Geolocation header 

• P-Access-Network-lnfo header 

• National solution to convey location information 
to make location information available for the PASP. 


Configuration 




SIP Parameter 


INVITE: Request line 

sip+ <(emergency number)>[; rn =+<(PASP routing number)] 
@hostname>;user = phone SIP/2.0 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
Apply post test routine 


Comments 


Check: Is the URI in the userinfo of the Request line in a global number format 

containing the PSAP routing number? 
Check: Optional: Is the URI 'rn' parameter containing the PASP Routing 

Number? 
Check: Is the user parameter set to 'phone'? 
Repeat this test in reverse direction. 
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7.6 SIP Support of Charging 



Test case number 


SS sipc 001 


Test case group 


SIP-SIP/ SIP charging 


Reference 


B.2.3/f19] 


SELECTION EXPRESSION 


SE16 


Test purpose 


Successful session from user A to user B via network B one single tariff. 

User A is located in network A and network B is responsible for charging (GDP) 
in case of carrier selection or service. Ensure that the network B sends a tariff 
information with one single tariff covered in a XML MIME body in a reliable 
provisional or successful final response. 


Configuration 




SIP Parameter 


INVITE: 

Supported: lOOrel 

18xor200OK 
Require: lOOrel 

GontentType: application/vnd.etsi.sci+xml 
Content-Disposition: render; handling=optional 

messageType 
crgt 

chargingControllndicators 
chargingTariff 
tariffCurrency 

currentTariffCurrency 

communicationChargeSequenceCurrency 
currencyFactorScale 
currencyFactor 
currencyScale 
tariffDuration 
subTariffControl 
tariff Controllndicators 
originationldentification 
currency (optional) 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
CASE A ^ 18x(crgt) 

PRACK ^ 
^ 200 OK PRACK 

CASE B ^ 200 OK INVITE(crgt) 

Apply post test routine 


Comments 


Check: Is the supported header in the initial INVITE set to 'lOOrel' 

Check: Is the Require header in the response containing the tariff information 

set to 'lOOrel'? 
Check: Is the messageType 'crgt' present in a 1xx provisional or a 200 OK 

INVITE final response? 
Check: Is the tariffCurrency element set to 'currentTariffCurrency'? 
Check: Represents the currencyFactorScale in the 

communicationChargeSequenceCurrency element the applicable 

tariff? 
Check: Is the tariffDuration element set to '0'? 
Check: Is the optional element 'currency' set to 'EUR' if present? 
Repeat this test in reverse direction. 
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Test case number 


SS sipc 002 


Test case group 


SIP-SIP/ SIP charging 


Reference 


B.2.3/f19] 


SELECTION EXPRESSION 


SE16 


Test purpose 


Successful session from user A to user B via network B several tariffs in 
one sequence. 

User A is located in network A and network B is responsible for charging (GDP) 
in case of carrier selection or service. Ensure that the network B sends a tariff 
information with several tariffs in a sequence covered in a XML MIME body in a 
reliable provisional or successful final response. 


Configuration 




SIP Parameter 


INVITE: 

Supported: lOOrel 

18xor200OK 
Require: lOOrel 

GontentType: application/vnd.etsi.sci+xml 
Content-Disposition: render; handling=optional 

messageType 

chargingControllndicators 
chargingTariff 
tariffCurrency 

currentTariffCurrency 

communicationChargeSequenceCurrency 
currencyFactorScale 
currencyFactor 
currencyScale 
tariffDuration 
subTariffControl 
communicationChargeSequenceCurrency 
currencyFactorScale 
currencyFactor 
currencyScale 
tariffDuration 
subTariffControl 
tariff Control Indicators 
originationldentification 
currency (optional) 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
CASE A ^ 18x(crgt) 

PRACK ^ 
^ 200 OK PRACK 

CASE B ^ 200 OK INVITE(crgt) 

Apply post test routine 


Comments 


Check: Is the Supported header in the initial INVITE set to '1 OOrel'? 

Check: Is the Require header in the response containing the tariff information 

set to 'lOOrel'? 
Check: Is the messageType 'crgt' present in a 1xx provisional or a 200 OK 

INVITE final response? 
Check: Is the tariffCurrency element set to 'currentTariffCurrency'? 
Check: Are there more than one communicationCharge 

SequenceCurrency elements present in the currentTariffCurrency 

element? 
Check: Represents the currencyFactorScale in the communicationCharge 

SequenceCurrency elements the applicable tariffs? 
Check: Is the tariffDuration element in the last applicable tariff set to '0'? 
Check: Is the optional element 'currency' set to 'EUR' if present? 
Repeat this test in reverse direction. 
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Test case number 


SS sipc 003 


Test case group 


SIP-SIP/ SIP charging 


Reference 


B.2.3/f19] 


SELECTION EXPRESSION 


SE16 


Test purpose 


Successful session from user A to user B via network B with call attempt 
charge. 

User A is located in network A and network B is responsible for charging (GDP) 
in case of carrier selection or service. Ensure that the network B sends a tariff 
information with a call attempt charge covered in a XML MIME body in a reliable 
provisional or successful final response. 


Configuration 




SIP Parameter 


INVITE: 

Supported: lOOrel 

18xor200OK 
Require: lOOrel 

GontentType: application/vnd.etsi.sci+xml 
Content-Disposition: render; handling=optional 

messageType 

chargingControllndicators 
chargingTariff 
tariffCurrency 

currentTariffCurrency 

communicationChargeSequenceCurrency 
currencyFactorScale 
currencyFactor 
currencyScale 
tariffDuration 
subTariffControl 
tariff Control Indicators 
callAttemptChargeCurrency 
currencyFactor 
currencyScale 
originationldentification 
currency (optional) 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
CASE A ^ 18x(crgt) 

PRACK ^ 
^ 200 OK PRACK 

CASE B ^ 200 OK INVITE(crgt) 

Apply post test routine 


Comments 


Check: Is the supported header in the initial INVITE set to 'lOOrel'? 

Check: Is the Require header in the response containing the tariff information 

set to 'lOOrel'? 
Check: Is the messageType a 'crgt' present in a 1xx provisional or a 200 OK 

INVITE final response? 
Check: Is the tariffCurrency element set to 'callAttemptChargeCurrency'? 
Check: Represents the currencyFactorScale in the 

callAttemptChargeCurrency element the applicable tariff? 
Check: Is the optional element 'currency' set to 'EUR' if present? 
Repeat this test in reverse direction. 
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Test case number 


SS sipc 004 


Test case group 


SIP-SIP/ SIP charging 


Reference 


B.2.3/f19] 


SELECTION EXPRESSION 


SE16 


Test purpose 


Successful session from user A to user B via network B with call setup 
charge. 

User A is located in network A and network B is responsible for charging (GDP) 
in case of carrier selection or service. Ensure that the network B sends a tariff 
information with a call setup charge covered in a XML MIME body in a reliable 
provisional or successful final response. 


Configuration 




SIP Parameter 


INVITE: 

Supported: lOOrel 

18xor200OK 
Require: lOOrel 

GontentType: application/vnd.etsi.sci+xml 
Content-Disposition: render; handling=optional 

messageType 

chargingControllndicators 
chargingTariff 
tariffCurrency 

currentTariffCurrency 

communicationChargeSequenceCurrency 
currencyFactorScale 
currencyFactor 
currencyScale 
tariffDuration 
subTariffControl 
tariff Control Indicators 
callSetupChargeCurrency 
currencyFactor 
currencyScale 
originationldentification 
currency (optional) 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
CASE A ^ 18x(crgt) 

PRACK ^ 
^ 200 OK PRACK 

CASE B ^ 200 OK INVITE(crgt) 

Apply post test routine 


Comments 


Check: Is the supported header in the initial INVITE set to 'lOOrel'? 

Check: Is the Require header in the response containing the tariff information 

set to 'lOOrel'? 
Check: Is the messageType a 'crgt' present in a 1xx provisional or a 200 OK 

INVITE final response? 
Check: Is the tariffCurrency element set to 'callSetupChargeCurrency'? 
Check: Represents the currencyFactorScale in the 

callSetupChargeCurrency element the applicable tariff? 
Check: Is the optional element 'currency' set to 'EUR' if present? 
Repeat this test in reverse direction. 
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Test case number 


SS sipc 005 


Test case group 


SIP-SIP/ SIP charging 


Reference 


B.2.3/f19] 


SELECTION EXPRESSION 


SE16 


Test purpose 


Successful session from user A to user B via network B with a next tariff. 

User A is located in network A and network B is responsible for charging (GDP) 
in case of carrier selection or service. Ensure that the network B sends a tariff 
information with a next tariff and tariff switch over time covered in a XML MIME 
body in a reliable provisional or successful final response. 


Configuration 




SIP Parameter 


INVITE: 

Supported: lOOrel 

18xor200OK 
Require: lOOrel 

ContentType: application/vnd.etsi.sci+xml 
Content-Disposition: render; handling=optional 

messageType 
crgt 

chargingControllndicators 
chargingTariff 
tariffCurrency 

currentTariffCurrency 

communicationChargeSequenceCurrency 
currencyFactorScale 
currencyFactor 
currencyScale 
tariffDuration 
subTariffControl 
tariff Controllndicators 
tariffSwitchCurrency 
nextTariffCurrency 

communicationChargeSequenceCurrency 
currencyFactorScale 
currencyFactor 
currencyScale 
tariffDuration 
subTariffControl 
tariff Controllndicators 


PlriHywitchOveriim^ 
originationldentification 
currency (optional) 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE ^ 
CASE A ^ 18x(crgt) 

PRACK ^ 
^ 200 OK PRACK 

CASE B ^ 200 OK INVITE(crgt) 

Apply post test routine 


Comments 


Check: Is the supported header in the initial INVITE set to 'lOOrel'? 

Check: Is the Require header in the response containing the tariff information 

set to 'lOOrel'? 
Check: Is the messageType 'crgt' present in a 1xx provisional or a 200 OK 

INVITE final response? 
Check: Is the tariffSwitchCurrency element set to 'nextTariffCurrency'? 
Check: Represents the currencyFactorScale in the 

communicationChargeSequenceCurrency element the next tariff? 
Check: Is the time to change the tariff indicated in the tariffSwitchOverlime 

element? 
Check: Is the optional element 'currency' set to 'EUR' if present? 
Repeat this test in reverse direction. 
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Test case number 


SS sipc 006 


Test case group 


SIP-SIP/ SIP charging 


Reference 


B.2.3/f19] 


SELECTION EXPRESSION 


SE16 


Test purpose 


Successful change of a current tariff and next tariff during an active 




session. 




User A is located in network A and network B is responsible for charging (CDP) 




in case of carrier selection or service. Ensure that the network B sends a new 




tariff information with several current tariffs and several next tariffs covered in a 




XML MIME body in an INFO request. 


Configuration 




SIP Parameter 


INFO 




ContentType: application/vnd.etsi.sci+xml 




messageType 




crgt 




chargingControllndicators 




chargingTariff 




tariffCurrency 




currentTariff Currency 




communicationChargeSequenceCurrency 




currencyFactorScale 




currencyFactor 




currencyScale 




tariffDuration 




subTariffControl 




communicationChargeSequenceCurrency 




currencyFactorScale 




currencyFactor 




currencyScale 




tariffDuration 




subTariffControl 




tariff Control Indicators 




tariffSwitchCurrency 




nextTariffCurrency 




communicationChargeSequenceCurrency 




currencyFactorScale 




currencyFactor 




currencyScale 




tariffDuration 




subTariffControl 




communicationChargeSequenceCurrency 




currencyFactorScale 




currencyFactor 




currencyScale 




tariffDuration 




subTariffControl 




tariff Control Indicators 




^riffSwitchOvel^H 




originationldentification 




currency (optional) 


Message flow 




SIP (Network A) 


Interconnection Interface SIP (Network B) 




A confirmed session already exists 




^ INFO 




200 OK INFO ^ 




Apply post test routine 


Comments 


Check: Is the messageType 'crgt' present in the INFO request? 




Check: Is the tariffCurrency element set to 'currentTariffCurrency'? 




Check: Represents the currencyFactorScale in the 




communicationChargeSequenceCurrency elements the current tariffs? 




Check: Is the tariffSwitchCurrency element set to 'nextTariffCurrency'? 




Check: Represents the currencyFactorScale in the 




communicationChargeSequenceCurrency elements the next tariffs? 




Repeat this test in reverse direction. 
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Test case number 


SS sipc 007 


Test case group 


SIP-SIP/SIP charging 


Reference 


B.2.3/f19] 


SELECTION EXPRESSION 


SE16 


Test purpose 


Successful additional charge during an active session. 

User A is located in network A and network B is responsible for charging (CDP) 
in case of carrier selection or service. Ensure that the network B sends a new 
tariff information with additional charge covered in a XML MIME body in an INFO 
request. 


Configuration 




SIP Parameter 


INFO 

ContentType: application/vnd.etsi.sci+xml 

messageType 
aocrg 

chargingControllndicators 
addOnCharge 

addOnChargeCurrency 
currencyFactor 
currencyScale 
originationldentification 
currency (optional) 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

A confirmed session already exists 

^ INFO 

200 OK INFO ^ 
Apply post test routine 


Comments 


Check: Is the messageType 'aocrg' present in the INFO request? 
Check: Is the addOnCharge element set to 'addOnChargeCurrency'? 
Check: Represents the currencyFactorScale the add on tariff? 
Repeat this test in reverse direction 



7.7 Quality of Service 
7.7.1 Reference Configurations 
7.7.1 .1 Backbone Configuration 

Figure 7.7-1 shows the backbone configuration. 




Figure 7.7-1 : Backbone 

7.7.1 .2 PSTN/ISDN classic access Configuration 

Figure 7.7-2 shows the PSTN/ISDN classic access configuration. 
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Figure 7.7-2: Reference configuration for PSTN/ISDN with classical access 
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7.7.1 .3 NGN PSTN/ISDN access Configuration 

Figure 7.7-3 shows the NGN PSTN/ISDN classic access configuration. 
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7.7.1.4 



Figure 7.7-3: Reference configuration for NGN with PSTN/ISDN access 



Access DSL Configuration 



Figure 7.7-4 shows the xDSL access configuration. 
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Figure 7.7-4: Reference configuration for DSL access 



7.7.1.5 



Delay Values 



The requirements for the backbone delay, Network parameters: End-to-End Delay, Talker Echo Loudness Rating, R 
Value Delay with regional propagation delay (1 400 km/11 ms) are contained in clause 4 of TR 102 775 [i.3] 

7.7.2 Test purposes for Quality of Service test 



Test case number 


88 qos 001 


Test case group 


8IP-8IP/Q08 


Transmission Type: 


Voice 


Preconditions user 
segment A: 


Reset Jitter Buffer 1 and Jitter Buffer 2 (e.g. by establishing a new call) 
Apply signal "single-talk" to Interface A and determine Delay Djbi 
Apply signal "single-talk" to Interface B and determine Delay Djb2 


Preconditions user 
segment B: 


Reset Jitter Buffer 1 and Jitter Buffer 2 (e.g. by establishing a new call) 
Apply signal single-talk to Interface A and determine Delay Djbi 
Apply signal single-talk to Interface B and determine Delay Djb2 


Requirement 


DjBi = DjB2 Delay jitter for Voice 


Test objective 


Delay Voice test with loopback 


IVIeasurement procedure 


After establishing a voice call from the user segment A to user segment B, determine the 

round trip delay in the sending and receiving direction. Based on the 

measured delays in the user segment A and user segment B determine the transit 

segment delay. 

Loop in user segment B 

Dtr seg A-B = (Dsum seg A-B" DjBlseg B" DjB2segA)/2 

Loop in user segment A 

Dtr seg B-A = (Dsum seg B-A " DjBlseg B" DjB2segA)/2 


Calling station 


The amplitude of the tone is -16 dBmO 


Called station 


The amplitude of the tone is -16 dBmO 


Delay loop 


1 000 ms 
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Test case number 


SS qos 002 


Test case group 


SIP-SIP/QoS 


Transmission Type: 


Voice 


Preconditions user 
segment A: 


Reset Jitter Buffer 1 and Jitter Buffer 2 (e.g. by establishing a new call) 
Apply signal "single-talk" to Interface A and determine Delay Djbi and Djb2 


Preconditions user 
segment B: 


Reset Jitter Buffer 1 and Jitter Buffer 2 (e.g. by establishing a new call) 
Apply signal "single-talk" to Interface A and determine Delay Djbi and Djb2 


Requirement 


DjBi = DjB2 Delay jitter for Voice 


Test objective 


Delay Voice test with synchronous tests system 


IVIeasurement procedure 


After establishing a voice call from the user segment A to user segment B, determine the 
delay of the end-to-end in the sending and receiving direction. Based on the 
measured delays in the user segment A and user segment B determine the transit 
segment delay. 

Dtr-segA-B= Dsum-seg A-B " DjBlsegB 
Dtr-seq B-A= Dsum-seq B-A" DjB2seqA 


Calling station 


The amplitude of the tone is -16 dBmO 


Called station 


The amplitude of the tone is -16 dBmO 
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